Re: GHC Logo

[Bardur Arantsson]

On 02/09/2020 00.36, Richard Eisenberg wrote:
> 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.
> 

(Apologies, Richard, for the double-send. Screwed up the to-all thing.)

Is there no animal which could reasonably be "overlaid" on the logo? I'm
thinking the `` bit would be horns or ears and the // would be legs...
Not sure what the = would be... maybe front legs/arms?

Afraid I cannot draw anything, but I did a *horrific* "rest of the owl"
type thing here:

   https://sketch.io/render/sk-a412a3154e2332ae6d1c58fb23f00c04.jpeg

Regards,



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab workflow

[Bardur Arantsson]

On 11/07/2019 17.47, Ben Gamari wrote:
[--snip--]

I'm just going to snip all of that because that was an almost perfect
summary of why rebase-always is best.

I'm *not* talking about rebasing willy-nilly, but I agree that rebasing
private branches and rebasing-with-agreement is superior in every way to
the just-merge-things approach... and you formulated it perfectly. Thank
you.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Bardur Arantsson]

On 28/03/2019 14.58, Oleg Grenrus wrote:
> There is. Add
> 
>     write-ghc-environment-files: never
> 
> to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later.
> 

That doesn't really work if you actually want to be able to use both
ways of working, does it? That same thing applies to

  export GHC_ENVIRONMENT=-

which someone else posted, but at least that can be done by tooling
before invoking ghc. It's odd to have to change a global setting to
avoid this. (However, thanks for the hints -- I'll be setting that
GHC_ENVIRONMENT from now on.)

+1 for changing the default.

It seems really weird to force other tooling to opt out when this could
easily be solved by just having

   cabal ghci
   cabal ghc

commands which set up the environment properly and tell users to use
that if they want to use cabal's environment files. FWIW, I also see
e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas
e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not
something users should really be running unless they know what they're
doing *and* it should be as tooling-friendly as possible.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RTS changes affect runtime when they shouldn’t

[Bardur Arantsson]

On 2017-09-23 20:45, Sven Panne wrote:
> 2017-09-21 0:34 GMT+02:00 Sebastian Graf  >:
> 
> [...] The only real drawback I see is that instruction count might
> skew results, because AFAIK it doesn't properly take the
> architecture (pipeline, latencies, etc.) into account. It might be
> just OK for the average program, though.
> 
> 
> It really depends on what you're trying to measure: The raw instruction
> count is basically useless if you want to have a number which has any
> connection to the real time taken by the program. The average number of
> cycles per CPU instruction varies by 2 orders of magnitude on modern
> architectures, see e.g. the Skylake section
> in http://www.agner.org/optimize/instruction_tables.pdf (IMHO a
> must-read for anyone doing serious optimizations/measurements on the
> assembly level). And these numbers don't even include the effects of the
> caches, pipeline stalls, branch prediction, execution units/ports, etc.
> etc. which can easily add another 1 or 2 orders of magnitude.
> 
> So what can one do? It basically boils down to a choice:
> 
>    * Use a stable number like the instruction count (the "Instructions
> Read" (Ir) events), which has no real connection to the speed of a program.
> 
>    * Use a relatively volatile number like real time and/or cycles used,
> which is what your users will care about. If you put a non-trivial
> amount of work into your compiler, you can make these numbers a bit more
> stable (e.g. by making the code layout/alignment more stable), but you
> will still get quite different numbers if you switch to another CPU
> generation/manufacturer.
> 
> A bit tragic, but that's life in 2017... :-}
> 
> 

I may be missing something since I have only quickly skimmed the thread,
but...: Why not track all of these things and correlate them with
individual runs? The Linux 'perf' tool can retrieve a *lot* of
interesting numbers, esp. around cache hit rates, branch predicition hit
rates, etc.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC release timing and future build infrastructure

[Bardur Arantsson]

On 2017-08-02 21:26, Bardur Arantsson wrote:

> I'd like to add a few thoughs (or just to underscore the ones you've
> already brought forth, as the case may be):
> 
[--snip--]
> reasons -- I wouldn't presume to know. Also note that this is
> *basically* how Rust also works, it's just that they keep the "unstable"
> bits behind a feature flag (until they're deemed 'stable') instead of
> actually having different code bases.
> 

Sorry about the self-reply and excesive bolding-for-emphasis. The point
of this past paragraph was that *perhaps* GHC could move towards
(short-lived!) "feature flags" for the compiler[1]. Again, I have no
experience with the GHC development process so maybe it's completely
absurd to even contemplate such a thing (in terms of effort).

Continuing with the thought from [1]: What if there were "stability
tiers" of LANGUAGE PRAGMA? Obviously, it doesn't *literally* have to be
like that, but maybe the concept works?

[1] I suppose LANGUAGE Pragmas are *kind* of like feature flags, but IME
LANGUAGE Pragmas tend to be actually be quite long-lived.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC release timing and future build infrastructure

[Bardur Arantsson]

On 2017-08-01 15:05, Ara Adkins wrote:
> Heya,
> 
> I very much agree with the thoughts on the variability of the release
> cadence. The following is somewhat of a stream of consciousness as I
> read, so please excuse any lack of coherence. 
> 
> When you talk about the bugs being significant blockers to the latest
> release I feel like that kind of issue isn't necessarily touched by
> moving to a shorter release cadence. In fact if we're unwilling to let
> certain fixes wait a release then it exacerbates the risk of slowing
> down a release. I'm not really sure what to do about this, other than
> adopting the mentality that fixes might not make the major release and
> will have to come in a point upgrade if they can't be merged to the
> release branch in time. 
> 
> Regarding the benefits of an abbreviated release cycle, we see it quite
> a lot in the rust community. There's a good amount of community
> involvement with the new releases, and new features are hotly
> anticipated as they often occur on a timescale where the enthusiasm is
> still there. I also feel, though this is purely anecdotal, that the more
> agile release schedule encourages community contributions as the
> tangible benefits of contributor work can be realised much more quickly.
> The number of RFCs in discussion at the moment is evidence of that, I feel. 

(Sorry, this is also kind of a braindump.)

I'd like to add a few thoughs (or just to underscore the ones you've
already brought forth, as the case may be):

- In the case of e.g. the Linux kernel, there's a pretty good assurance
that *someone* will maintain a "stable" release of a reasonably-recent
version of the kernel and backport(!) patches for, say, up to a year
(either distros or the 'stable' kernel maintainer & co). In the case of
the Linux kernel backporting will *usually* not be that much work, but
in the case of GHC it *might* be a lot more work for any number of
reasons -- I wouldn't presume to know. Also note that this is
*basically* how Rust also works, it's just that they keep the "unstable"
bits behind a feature flag (until they're deemed 'stable') instead of
actually having different code bases.

- Releasing often means that *all* the upstreams who care(!) get to
"start" early as well. (RCs notwithstanding) See e.g. Stackage.

- Releasing often means that any serious bugs that get into a release
can also get a *release* that fixes them ASAP (and this is important:)
*independent* of any other release-blocking bugs in *upcoming* features.
This is a Big Deal(TM) and I think it's why the Linux kernel model works
at all.

- Releasing often means that there isn't this absolutely mad rush to get
$YOUR_FEATURE in before the deadline, because what's another 3/6 months
in the grand scheme of things? When you don't know if $FEATURE will make
it in in ½ year or 2 years, then it's a problem -- and you rush like mad
(likely making miskakes in the process).

- As a corollary to that: It is *paramount* that the release schedule is
adhered to *quite* strictly. This is also, I believe, key to its success
in the Linux kernel and Rust community. It doesn't matter much if
feature "X" makes it in -- it'll be in the next soon-to-come release.

- And, yes, this means a serious committment to improving the
tooling/automation around GHC releases.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Which stable GHC release is expected to have support for linear types?

[Bardur Arantsson]

On 2017-07-14 21:59, Wolfgang Jeltsch wrote:
> Am Freitag, den 14.07.2017, 06:42 +0200 schrieb Bardur Arantsson:
>> On 2017-07-14 01:26, Mike Ledger wrote:
>>> How about: -+
>>>
>>> It almost looks arrow like if you squint, and have a font that lines
>>> up the horizontal lines.
>>
>> This may play havoc with programming fonts with ligatures where it
>> might be rendered as a single ± symbol.
>>
>> (I haven't tested any of the fonts, I'm just saying it _could_ be an
>> issue.)
> 
> I would expect such fonts to translate “+-”, not “-+”, into “±”.
> 

Maybe, but it seems a bit fragile to me...

What about -*? At least there's no ambiguity there.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Which stable GHC release is expected to have support for linear types?

[Bardur Arantsson]

On 2017-07-14 01:26, Mike Ledger wrote:
> How about: -+
> 
> It almost looks arrow like if you squint, and have a font that lines up
> the horizontal lines.
> 

This may play havoc with programming fonts with ligatures where it might
be rendered as a single ± symbol.

(I haven't tested any of the fonts, I'm just saying it _could_ be an issue.)

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Attempt at a real world benchmark

[Bardur Arantsson]

On 2016-12-09 08:31, Bardur Arantsson wrote:

> Actually, now that I think about it: What about if this were integrated
> into the Cabal infrastructure? If I specify "upload-perf-numbers: True"
> in my .cabal file, any project on (e.g.) GitHub that wanted to opt-in
> could do so, they could build using Travis, and voila!
> 

Post-shower addendum:

If we had the right hooks in Cabal we could even also track the
*runtimes* of all the tests. (Obviously a bit more brittle because one
expects that adding tests would cause a performance hit, but could still
be valuable information for the projects themselves to have -- which
could be a motivating factor for opting in to this scheme.)

Obviously it would have to be made very easy[1] to compile with GHC HEAD
on travis for this to have much value for tracking regressions "as they
happen" and perhaps a "hey-travis-rebuild-project" trigger would have to
be implemented to get daily/weekly builds even when the project itself
has no changes.

We could perhaps also marshal a bit of the Hackage infrastructure
instead? Anyway, loads of variations on this theme. The key point here
is that the burden of keeping the "being tested" code working with GHC
HEAD is on the maintainers of said projects... and they already have
motivation to do so if they can get early feedback on breakage og
regressions on compile times and run times.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Attempt at a real world benchmark

[Bardur Arantsson]

On 2016-12-08 17:04, Joachim Breitner wrote:
> Hi,
> 
> Am Donnerstag, den 08.12.2016, 01:03 -0500 schrieb Joachim Breitner:
>> I am not sure how useful this is going to be:
>>  + Tests lots of common and important real-world libraries.
>>  − Takes a lot of time to compile, includes CPP macros and C code.
>> (More details in the README linked above).
> 
> another problem with the approach of taking modern real-world code:
> It uses a lot of non-boot libraries that are quite compiler-close and
> do low-level stuff (e.g. using Template Haskell, or stuff like the). If
> we add that not nofib, we’d have to maintain its compatibility with GHC
> as we continue developing GHC, probably using lots of CPP. This was
> less an issue with the Haskell98 code in nofib.
> 
> But is there a way to test realistic modern code without running into
> this problem?
> 

This may be a totally crazy idea, but has any thought been given a
"Phone Home"-type model?

Very simplistic approach:

  a) Before it compiles, GHC computes a hash of the file.
  b) GHC has internal profiling "markers" in its compilation pipeline.
  c) GHC sends those "markers" + hash to some semi-centralized
highly-available service somewhere under *.haskell.org.

The idea is that the fact that "hashes are equal" => "performance should
be comparable". Ideally, it'd probably be best to be able to have the
full source, but that may be a tougher sell, obviously.

(Obviously would have to be opt-in, either way.)

There are a few obvious problems with this, but an obvious win would be
that it could be done on a massively *decentralized* scale. Most
problematic part might be that it wouldn't be able to track things like
"I changed $this_line and now it compiles twice as slow".

Actually, now that I think about it: What about if this were integrated
into the Cabal infrastructure? If I specify "upload-perf-numbers: True"
in my .cabal file, any project on (e.g.) GitHub that wanted to opt-in
could do so, they could build using Travis, and voila!

What do you think? Totally crazy, or could it be workable?

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How, precisely, can we improve?

[Bardur Arantsson]

On 2016-09-30 19:26, Carter Schonwald wrote:
> We all do!.

I dont.

(Sorry, just had to put that Monty Python joke in there. At least I
*think* it was MP?)

Obviously, yes, we all *really* *REALLY* like Haskell, otherwise we
wouldn't be arguing about it, would we? ;)

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

(Sorry if anybody receives this twice, I think I flubbed my 'send'.)

On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote:
> Yet my vote is with "bespoke". Short, informative, recognizable, and a
> nice balance of quirky and reasonable, just like so much else here.
> 

... oh, and might I submit the opinion that quirky is not a quality that
to be desired of a programming language, even if it's only a keyword?

(Anyway, I think I'll stop here. This is too much opinion for any
further discussion to be useful.)

Regards,


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote:
>> Honestly, I don't care particularly much which exact word it becomes
>> just as long at isn't some 'cute' or obscurse[1] word.
>>
>> 'magic' belongs in the 'cute' category, I think and 'bespoke' belongs in
>> the latter.
> I'm native German. I never was in any English-speaking country in my
> life. Almost all my English media is from the USA. I'm not a tailor. Yet
> "bespoke" was familiar and instantly tells me what's important.
> So I may just be one point on the map, but I am not sure your argument
> that it is "obscure" is valid, sorry.
> 
> That being said, let me add a package of "a"s for all the times an
> English native complains that he has to learn a new word to program.
> Take a portion and pass it along, would you? ;)
> 
> Apropos learning words: while searching for information if "bespoke" is
> really obscure (I found none in either direction) I stumbled upon some
> (I think) not-yet-mentioned possible options
> 

I said it was *needlessly* obscure. There's absolutely no reason to
choose such a word in this case.

> * custom(i[zs]ed)?

This seems to convey the exact opposite when used in the programming
domain. When I 'customize' something or specify a 'custom' $something, I
expect that I, the programmer, am going to provide the
logic/behavior/whatever.

> * tailored

Just as 'bad' as bespoke -- and still has a sort of feeling of
'customized'. Bespoke at least has the very strong connotation of
"getting someone else to do it for you" whereas tailored doesn't *quite*
have that. (All, IMO, of course.)

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-19 03:45, Baldur Blöndal wrote:
> I haven't followed the thread but do we actually need a name for it,
> can't it be indicated by omission?
> ‘default’ or ‘builtin’ sounds okay

'default' is good too, IMO.



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-18 20:46, Ryan Scott wrote:
> Bardur,
> 
> Since you don't like "bespoke", would you mind suggesting an
> alternative, or advocating for a previously mentioned idea? From [1],
> the ideas I've seen tossed around are:
> 
> * builtin
> * standard (Elliot Cameron suggested it here [2])
> * wiredin (Cater Schonwald suggested it here [3])
> * magic (Andres Löh suggested it here [4])
> * native
> * original
> * specialized (the above three are ad hoc suggestions I came up with
in a hurry)

(I think I did suggest 'builtin', but it was buried in a sentence, so it
was easy to miss.)

Honestly, I don't care particularly much which exact word it becomes
just as long at isn't some 'cute' or obscurse[1] word.

'magic' belongs in the 'cute' category, I think and 'bespoke' belongs in
the latter.

Of the remaining alternatives I like 'builtin' and 'standard' the best,
simply because they're common and not all that overloaded when it comes
to their meaning in programming languages.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-18 07:44, Malcolm Wallace wrote:
> 
> On 18 Aug 2016, at 06:34, Bardur Arantsson wrote:
> 
>> Not a native (British) English speaker, but I've consumed a *lot* of UK
>> media over the last ~25-30 years and I can literally only recall having
>> heard "bespoke" used *once* and that was in the term "bespoke suit"
>> where you can sort-of guess its meaning from context. I believe this is
>> also the only context in which it's actually really used in British
>> English. (However, I'll let the native (British) English speakers chime
>> in on that.)
> 
> "Bespoke" is a reasonably common British English word, used in all of the 
> following phrases:
> 
> bespoke software
> bespoke solution
> bespoke furniture
> bespoke kitchen
> bespoke tailoring
> 
> The meaning is "specially and individually made for this client".  The 
> opposite of standard, off-the-shelf, pre-packaged.  It implies the outcome 
> was not automatable, even if the individual pieces being assembled were 
> machine-cut.
> 

Thanks,

Mildly interestingly, both the online M-W and the online OED list only
the clothing by example. (Though the definitions don't *preclude* any
other type of goods.)

> "In the U.S., bespoke software is often called custom or custom-designed 
> software." http://whatis.techtarget.com/definition/bespoke
> 

AFAIUI "custom", alas, doesn't really work in this context. :(

Anyway, regardless of all that: "bespoke" is still a needlessly obscure
word, IMO. Ergonomics matter in programming languages.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-12 20:31, Ryan Scott wrote:
> On the subject of alternative names, you may be interested in reading
> this section of the DerivingSyntax wiki page [2], which lists other
> names besides "bespoke" and "builtin" that have been tossed around as
> ideas. They include:
> 
> * magic
> * wiredin
> * standard
> * native
> * original
> * specialized
> 

Can we please just go with the obvious "builtin"? There's no need for
willful obscurity here.

Not a native (British) English speaker, but I've consumed a *lot* of UK
media over the last ~25-30 years and I can literally only recall having
heard "bespoke" used *once* and that was in the term "bespoke suit"
where you can sort-of guess its meaning from context. I believe this is
also the only context in which it's actually really used in British
English. (However, I'll let the native (British) English speakers chime
in on that.)

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is Safe Haskell intended to allow segfaults?

[Bardur Arantsson]

On 2016-08-12 20:37, Edward Kmett wrote:
> What about consuming Storable Vectors carefully, or simply working
> parameterized over vector type, where Storable vectors are one of the
> options?
> 

There was actually a great paper about a very similar thing (i.e.
"here's the usual interface" vs. "here's how it should be done") recently:

http://ozark.hendrix.edu/~yorgey/pub/twisted.pdf

It may be of interest -- at least as far as an "improved Ptr/Storable" goes.

Cheers,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-05 11:06, Ben Gamari wrote:
> Ryan Scott  writes:
> 
>> Sorry for not including the full context on that link. It's part of a
>> Summer of Haskell 2016 project called Native Metaprogramming in
>> Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix
>> Trac #11081 [3].
>>
> On this note, it would be great to hear a bit about the state of this
> project. Shayan, have you written anything describing how things are
> going? It would be great if you could update the Wiki page [2]
> describing a bit about the approach you have taken and the current state
> of your implementation.
> 

Just a little aside: AFAICT the idea here was originally to reuse the
compiler's internal AST representation. I'd be really interested to hear
if that's changed.

This compes along with a little cautionary note: The Scala people
originally did this for their macro support and it's being abandoned in
favor of something called TASTY which is a different (simplified?)
representation of the Scala AST. (There were a lot of other problems
with the Scala macro implementation which is caused by simply being
intimately tied to compiler internals in *other* ways.) Obviously, all
of this is AFAIUI and my understanding may not exactly be great, but
regardless I think it's worth looking into Scala/TASTY and why the Scala
people have (apparently) chosen it as the solution over the existing one.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-04 02:50, Ryan Scott wrote:
>  I'm
> holding out hope that the work in
> https://github.com/shayan-najd/NativeMetaprogramming makes things
> nicer soon, and then we can revisit this idea.

Are there any papers on this? (Or even just blog posts and such.) Sounds
really intriguing, but obvious searches didn't find anything.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal process status

[Bardur Arantsson]

On 07/21/2016 08:38 PM, Richard Eisenberg wrote:
> 
>> On Jul 21, 2016, at 2:25 PM, Yuras Shumovich  wrote:
>>
[--snip--]
>> Haskell Prime committee will never catch up if GHC will continue
>> adding new extensions.
> 
> Of course not. But I believe some libraries also refrain from using new 
> extensions for precisely the same reason -- that the new extensions have yet 
> to fully gel.
> 

Indeed, a major issue right now is that Haskell-as-practiced is *sooo*
far from Haskell-as-standardized (H2010) that it's basically hopeless to
implement most non-trivial things using only H2010. We're not even
talking missing very advanced things, just "basic" things like MPTCs,
ScopedTypeVariables not being the standard behavior, various
derivations, auto-Typeable, TypeFams vs. FunDeps[1], plus various minor
syntactic conveniences[2], BangPatterns, etc. etc.

Just FTR: Of course, I realize that standardizing any of this is *much*
easier said than done, so this is NOT meant as a slight against anyone!

Regards,

[1] Alright, this one might be a little more contentious, but the basic
functionality of FunDeps (or the equivalent functionality form TypeFams)
is sometimes necessary.

[2] These I can and will work around if necessary, but as long as
something else in my package requires anything non-Haskell2010, why
should I bother?


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Moving ArgumentsDo forward

[Bardur Arantsson]

On 06/01/2016 01:48 PM, Akio Takano wrote:
> Hi,
> 
> Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would
> love to see in GHC. It's a small syntactic extension that allows do,
> case, if and lambda blocks as function arguments, without parentheses.
> However, its differential revision [1] has been abandoned, citing a
> mixed response from the community. A message [2] on the ticket
> summarizes a thread in haskell-cafe on this topic.
> 
> I, for one, think adding this extension is worthwhile, because a
> significant number of people support it. Also, given how some people
> seem to feel ambivalent about this change, I believe actually allowing
> people to try it makes it clearer whether it is a good idea.
> 
> Thus I'm wondering: is there any chance that this gets merged? If so,
> I'm willing to work on whatever is remaining to get the change merged.
> 

What's changed since it was last discussed? I don't think the objections
were centered in the implementation, so I don't see what "whatever is
remaining to get the change merged" would be.

AFAICT at best it's a *very* small improvement[1] and fractures Haskell
syntax even more around extensions -- tooling etc. will need to
understand even *more* syntax extensions[2].

Regards,

[1] If you grant that it is indeed an improvment, which I, personally,
don't think it is.

[2] I think most people agree that this is something that should perhaps
be handled by something like
https://github.com/haskell/haskell-ide-engine so that it would only need
to be implemented once, but there's not even an alpha release yet, so
that particular objection stands, AFAICT.


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: perf.haskell.org’s list of branches got more useful

[Bardur Arantsson]

On 04/26/2016 11:11 PM, Joachim Breitner wrote:
> Hi,
> 
> Am Dienstag, den 26.04.2016, 16:57 +0200 schrieb Bardur Arantsson:
>> On 04/26/2016 01:09 PM, Joachim Breitner wrote:
>>> * What does "2 days ago" mean?
>>> The age of the latest commit to the branch.
>>>
>> FWIW, I think adding a few simple table headings might help
>> enormously.
>>
>> "Last commit", "?", "Branch", "Last commit message", "Diffstat".
>>
>> (or something like that.)
> 
> good idea; although often with tables space is thight, and narrow
> columns don’t allow for wide enough headers.
> 

You can always shorten the text or use abbreviations and then add hover
text with the 'full name' of the column. Mouse hover text isn't *great*
UX-wise, but probably better than nothing. It's generally a little less
'discoverable' even if people are generally used to the idea of hover
tooltips. Additionnaly, I'm not sure how well this will work for blind
people who use screen readers.

Regards,


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: perf.haskell.org’s list of branches got more useful

[Bardur Arantsson]

On 04/26/2016 01:09 PM, Joachim Breitner wrote:
> Hi,
> 
>  
>> * What does "2 days ago" mean?
> 
> The age of the latest commit to the branch.
> 

FWIW, I think adding a few simple table headings might help enormously.

"Last commit", "?", "Branch", "Last commit message", "Diffstat".

(or something like that.)


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

[Bardur Arantsson]

On 02/06/2016 03:55 PM, Roman Cheplyaka wrote:
> But despite all the negativity in this thread, I want to say that your
> work on this and other aspects of GHC is very much appreciated. Keep it up!
> 

+1000


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: "Excuse me, I think this i my stop..." - Resigning from the Platform

[Bardur Arantsson]

On 10/13/2015 05:08 AM, Mark Lentczner wrote:
> I think this is the right time for me to exit:
> 

I'm pretty sure that there are many things that we could agree or
disagree on, but *THANK YOU* for your efforts on improving the Haskell
ecosystem and your efforts to spread the word!

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: more releases

[Bardur Arantsson]

On 09/07/2015 04:57 PM, Simon Peyton Jones wrote:
> Merging and releasing a fix to the stable branch always carries a cost:
> it might break something else.  There is a real cost to merging, which
> is why we've followed the lazy strategy that Ben describes.
> 

A valid point, but the upside is that it's a very fast operation to
revert if a release is "bad"... and get that updated release into the wild.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Bardur Arantsson]

On 09/03/2015 09:18 AM, Joe Hillenbrand wrote:
>> As a wild idea -- did anyone look at /Gitlab/ instead?
> 
> My personal experience with Gitlab at a previous job is that it is
> extremely unstable. I'd say even more unstable than trac and
> phabricator. It's especially bad when dealing with long files.
> 

If we're talking alternative systems, then I can personally recommend
Gerrit (https://www.gerritcodereview.com/) which, while it *looks*
pretty basic, it  works really well with the general Git workflow. For
example, it tracks commits in individual reviews, but tracks
dependencies between those commits. So when e.g. you push a new series
of commits implementing a feature, all those reviews just get a new
"version" and you can diff between different versions of each individual
commit -- this often cuts down drastically on how much you have to
re-review when a new version is submitted.

You can also specify auto-merge when a review gets +2 (or +1, or
whatever), including rebase-before-merge-and-ff instead of having merge
commits which just clutter the history needlessly.

You can set up various rules using a predicate-based rules engine, for
example about a review needing two approvals and/or always needing
approval from an (external) build system, etc.

The only setup it needs in a git hook... which it will tell you exactly
how to install with a single command when you push your first review.
(It's some scp command, I seem to recall.)

Caveat: I haven't tried using it on Windows.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Planning for the 7.12 release

[Bardur Arantsson]

On 08/28/2015 07:33 PM, Ben Gamari wrote:
 Simon Peyton Jones simo...@microsoft.com writes:
 
 Actually that’s a good idea.

 Simon


 From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Greg Weber
 Sent: 28 August 2015 16:43
 To: Ben Gamari
 Cc: GHC developers
 Subject: Re: Planning for the 7.12 release

 Can we call this GHC 8.0 instead of 7.12 ?
 Overloaded record fields and backtraces are a huge missing piece to
 Haskell. It would be nice to have the bump to celebrate this occasion
 and say that Haskell 8 is ready. I have had a hard time seriously
 recommending Haskell due to those last missing features. Now I should
 be able to say without reservation: use Haskell  8; it is great!

 I was discussing this very matter yesterday with a few folks. I think we
 certainly have enough features in this release to do a major bump. I
 half-jokingly suggested that 8.0 should only come with Phase 2 of
 Richard's Dependent Haskell work, but I'm willing to settle for
 merely kind equality.
 

That could be 9.0...? Let's embrace the Firefox/Chrome philosophy about
versioning :)

I'm very excited about the feature list for 7.12 and I agree that it's
almost big enough for a new major release.

(Thanks to all the people who've worked on it, btw!)

Cheers,



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Abstract FilePath Proposal

[Bardur Arantsson]

On 07/05/2015 12:27 AM, Brandon Allbery wrote:
 On Sat, Jul 4, 2015 at 6:17 PM, Bardur Arantsson s...@scientician.net
 wrote:
 
 Yes, the rest of the ecosystem may move along and use the latest new
 shiny, but then you can always use the packages that worked with GHC
 7.8.x thanks to version ranges.

 Am I missing something?

 
 Updates needed to fix e.g. security issues, which otherwise might not be
 backported if others are staying close to current. This is why Stackage has
 both LTS and Nightly; LTS only works if there's a *commitment* to it, at
 the level of the community for a community resource or at the level of the
 provider for something like ghc or Stackage.
 

How often have security issues with GHC (or the base libraries) itself
been a problem? (In practice, I mean.)

In my hypothetical scenario, there's nothing to prevent a release of

   GHC 7.8.(x+1)

while GHC 7.12. is the new thing. Nor does anything prevent library
releases of

 my-library-1.2.x (security patch)

while

 my-library-1.6.x

is the hot new thing.

 Note that GHC HQ's response was that they have had problems finding people
 to keep multiple versions active at the same time; it's a significant job
 given that backporting (say) a fix to a type system issue allowing
 unexpectedly unsafe code (say, https://ghc.haskell.org/trac/ghc/ticket/9858)
 can mean a complete redesign of the patch, if the one in HEAD relies on
 other changes that can't be sensibly backported.
 

Yes, there's a man-power problem... but that isn't going to be solved
unless some people/companies step up to the plate. Preferably the people
who are actually using/relying on those old versions. This is no
different from e.g. RHEL/Ubuntu LTS/Debian in the Linux world. (Well,
except RHEL actually has a revenue stream that means that they can and
do support old versions of various things.)

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Abstract FilePath Proposal

[Bardur Arantsson]

On 07/05/2015 08:40 PM, Brandon Allbery wrote:
 On Sun, Jul 5, 2015 at 2:25 PM, Bardur Arantsson s...@scientician.net
 wrote:
 
 How often have security issues with GHC (or the base libraries) itself
 been a problem? (In practice, I mean.)

 
 Not that often, but consider one real example: aeson was found to have a
 DDoS bug which was fixed by making it depend on a package which IIRC needed
 a newer base, so the fix couldn't be backported to versions of aeson
 compatible with older base. The necessary fix for those would have been
 substantially more complicated.
 
 (There are other examples, but the primary one that actually involves
 something shipped with ghc is never going to be fixed until it destroys
 someone's system, and I bet even then we'll get another load of HOMG MUST
 NEVER CHANGE API ONLY DOCUMENT AS BAD from the maintainer. I'm still
 waiting for one of the Linux distributions to notice and CVE it.)
 

Oh, yeah, that's a valid point... but is this something that should
drive design?

Further, I don't think the aeson DDoS problem was predicated on an
old/obsolete base library? Maybe I'm wrong about that, and I'm sure
y'all will be happy to point out where and why. :)

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Abstract FilePath Proposal

[Bardur Arantsson]

On 07/04/2015 09:38 PM, Brandon Allbery wrote:
 On Sat, Jul 4, 2015 at 3:26 PM, Sven Panne svenpa...@gmail.com wrote:
 
 To me the fundamental question which should be answered before any detail
 question is: Should we go on and continuously break minor things (i.e.
 basically give up any stability guarantees) or should we collect a bunch of
 changes first (leaving vital things untouched for that time) and release
 all those changes together, in longer intervals? That's IMHO a tough
 question which we somehow avoided to answer up to now. I would like to see
 a broader discussion like this first, both approaches have their pros and
 cons, and whatever we do, there should be some kind of consensus behind it.
 
 
 I recall suggesting something along the lines of stable vs. research ghc
 releases a few months back. This seems like it would fit in fairly well;
 the problem is getting buy-in from certain parts of the ecosystem that seem
 to prefer to build production-oriented packages from research/unstable
 releases.
 

But isn't that effectively just the same as saying: In our organization
we'll be staying with GHC 7.8.x until GHC 7.12.x comes out? (Or
similar, I'm sure you get the point.)

Yes, the rest of the ecosystem may move along and use the latest new
shiny, but then you can always use the packages that worked with GHC
7.8.x thanks to version ranges.

Am I missing something?

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SV: Abstract FilePath Proposal

[Bardur Arantsson]

On 06/27/2015 11:33 AM, Niklas Larsson wrote:
 Hi!
 
 Instead of trying to minimally patch the existing API and still
 breaking loads of code, why not make a new API that doesn't have
 to compromise and depreciate the old one?


This is a good idea in theory, but it's how we end up in situations like

   https://xkcd.com/927/

:)

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Abstract FilePath Proposal

[Bardur Arantsson]

On 06/26/2015 06:08 PM, Herbert Valerio Riedel wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hello *,
 
 What?
 =
 
[--snip--]

I am *entirely* behind this in priciple and if it doesn't break too much
of Hackage, also in practice, but...

... how much of Hackage *does* this break?

The reason that I'm in favor in principle is that paths really *are*
opaque things -- platforms have entirely different conventions. AFAICT
the only thing that they seem to agree on is that there is a hierarchy
of some sort. (And not much else, including such things as case
(in-)sensivity or character sets.). For example, in POSIX they're just
strings of bytes without any specified encoding, and I'd love if they
could be make to work like that when dealing with files in Haskell.

Regards,


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

[Bardur Arantsson]

On 05/21/2015 12:31 PM, Herbert Valerio Riedel wrote:
 Hi Yitzchak,
 
 On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote:
 
 [...]
 
 Bardur Arantsson wrote:
 I don't see any need for an option. Just bundle cpphs together with GHC
 and build/use it as an external program. AFAICT this has absolutely no
 licensing implications for GHC, derived from GHC or anything compiled
 with GHC.

 Agreed, that would work. But I thought that the idea was that we wanted
 it actually integrated into GHC.
 
 That would be the preferred way from a technical standpoint, as it would
 avoid fork/exec and make it easier to integrate the CPP-phase tighter
 into the lexer/parser.

fork/exec is almost certainly going to be negligable compared to the
overall compile time anyway. It's not like GHC is fast enough for it to
matter.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] RFC: Native -XCPP Proposal

[Bardur Arantsson]

On 05/21/2015 05:36 PM, Malcolm Wallace wrote:
 
 On 21 May 2015, at 15:54, Bardur Arantsson wrote:
 
 fork/exec is almost certainly going to be negligable compared to the
 overall compile time anyway. It's not like GHC is fast enough for it to
 matter.
 
 Don't count on it.  On our Windows desktop machines, fork/exec costs 
 approximately one third of a second, instead of the expected small number of 
 milliseconds or less.  The reasons are unknown, but we suspect a 
 misconfigured anti-virus scanner (and for various company policy reasons we 
 are prohibited from doing the investigation that could confirm or deny this 
 hypothesis).
 

Yeah, that sounds... broken.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

[Bardur Arantsson]

On 05/20/2015 03:39 PM, Yitzchak Gale wrote:
[--snip--]
 Keeping the license as is seems to be important to Malcolm.
 So could we have an option to build GHC without cpphs
 and instead use it as a stand-alone external program?
 That would make the situation no worse than GMP.

I don't see any need for an option. Just bundle cpphs together with GHC
and build/use it as an external program. AFAICT this has absolutely no
licensing implications for GHC, derived from GHC or anything compiled
with GHC.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Native -XCPP Proposal

[Bardur Arantsson]

On 05/19/2015 07:31 AM, Carter Schonwald wrote:
 I imagine your ghc build uses gcc to invoke the system assembler and linker
 on your Linux servers, :-) and that's gplv3!

That is of no consequence licensing-wise since those are

   a) separate programs/executables, thus derived work doesn't enter
  into it at any level, except...

   b) if the output contains bits of of the programs themselves, but
  e.g. gcc (and one assumes the linker, etc.) have specific
  licensing exemptions for the output.

(And this *is* something that you can quickly explain to the lawyerly
types.)

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Native -XCPP Proposal

[Bardur Arantsson]

On 05/19/2015 08:26 AM, Bardur Arantsson wrote:
 On 05/19/2015 07:31 AM, Carter Schonwald wrote:
 I imagine your ghc build uses gcc to invoke the system assembler and linker
 on your Linux servers, :-) and that's gplv3!
 
 That is of no consequence licensing-wise since those are
 
a) separate programs/executables, thus derived work doesn't enter
   into it at any level, except...
 
b) if the output contains bits of of the programs themselves, but
   e.g. gcc (and one assumes the linker, etc.) have specific
   licensing exemptions for the output.
 
 (And this *is* something that you can quickly explain to the lawyerly
 types.)
 

Oh, and it's also pretty well-established at this point, though I'm not
aware of any specific cases that have gone to the courts.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Native -XCPP Proposal

[Bardur Arantsson]

On 05/19/2015 11:04 AM, Boespflug, Mathieu wrote:
 On 19 May 2015 at 08:26, Bardur Arantsson s...@scientician.net wrote:
 
 On 05/19/2015 07:31 AM, Carter Schonwald wrote:
 I imagine your ghc build uses gcc to invoke the system assembler and
 linker
 on your Linux servers, :-) and that's gplv3!

 That is of no consequence licensing-wise since those are

a) separate programs/executables, thus derived work doesn't enter
   into it at any level, except...

b) if the output contains bits of of the programs themselves, but
   e.g. gcc (and one assumes the linker, etc.) have specific
   licensing exemptions for the output.

 (And this *is* something that you can quickly explain to the lawyerly
 types.)
 
 
 Both conditions likewise hold true for
 cpphs-as-an-external-process-bundled-with-GHC. So any particular remaining
 concern there?
 
 

Not from me, certainly. I was just trying to point out that the example
given (Linux, gcc, ...) was invalid.

I would be more worried about e.g. Linux distributions *if* cpphs were
under some weird license, but since it's LGPL that shouldn't prompt any
issues. (We're talking mere aggregation in the terms used in the GPL.)

As always, IANAL and in particular I am not *your* or anybody else's
lawyer :).

Regards,


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] RFC: Native -XCPP Proposal

[Bardur Arantsson]

On 06-05-2015 16:32, Sven Panne wrote:
 2015-05-06 16:21 GMT+02:00 Bardur Arantsson s...@scientician.net:
 +1, I'll wager that the vast majority of usages are just for version
 range checks.
 
 The OpenGL-related packages used macros to generate some binding magic
 (a foreign import plus some helper functions for each API entry),
 not just range checks. I had serious trouble when Apple switched to
 clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources
 had been checked in. :-P Nowadays the binding is generated from the
 OpenGL XML registry file, so this is not an issue anymore.

Ok, so it's *not* a counterexample :).

 
 If there are packages that require more, they could just keep using the
 system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd
 want to see real evidence that that's actually worth the
 effort/complication.
 
 Simply relying on the system CPP doesn't work due to the various
 differences between GCC's CPP and the one from clang, see e.g.
 https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380.
 Ignoring the problem doesn't make it go away... ;-)
 

No, but is it worth the effort? (As opposed to workarounds, such as just
checking in the preprocessed file as you provided an example of.)

 Note that we still need CPP to handle the various calling conventions
 on the different platforms when the FFI is used, so it's not only
 range checks, see e.g.
 https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588.
 

Certainly. I'm not saying *everybody* just does range checks, but I'm
guessing that it's the majority of CPP users are using it just for that.

(I'm not going to be doing any of the work, so this is just armchairing,
but this seems like an 80/20 solution would be warranted.)

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: wither the Platform

[Bardur Arantsson]

On 25-03-2015 15:24, Mark Lentczner wrote:

 Concrete proposal based on that and the other fine input in the responses:
 
 *Simultaneous Release:* Since it is organizationally impractical to have
 one release, let's have GHC and Platform release at the same moment. That
 is, GHC HQ would keep a release in RC until HP was ready. By the same
 token, HP team commits to tracking GHC from RC1, and aiming to hit ready
 for release within a week of GHC being ready. Both go release in the same
 announcement. *In fact, let's version HP with the same number as GHC!*

What is the purpose of doing this? It's not clear to me that there's any
upside, only the rather large downside of GHC HQ (and thus some of us
downstreams) having to wait arbitrarily long for the HP release. The
historical record for timeliness of HP releases is not encouraging. Are
we just expecting that the HP will somehow magically attract more
developers... which will somehow translate into more timely releases?

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Delaying 7.10?

[Bardur Arantsson]

On 01/29/2015 08:54 PM, Austin Seipp wrote:
 After thinking about it a little, I'm fine with pushing the release out to
 March. I think #9858 is the more serious of our concerns vs a raging
 debate, too.
 
 My only concern really is dealing with the merging of such a patch. For
 example, if the patch to fix this is actually as wide ranging as we believe
 to the type hacker, I can definitely foresee a merge conflict, with, say,
 the recent -fwarn-redundant-constraints, which I've managed to leave out of
 7.10 so far.
 
 In any case, with some more time, we can work those details out.

Oh, you silly implementers, you! :D

Regards,


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC support for the new record package

[Bardur Arantsson]

On 2015-01-21 17:01, Johan Tibell wrote:
 My thoughts mostly mirror those of Adam and Edward.
[--snip--]
 
 3) I don't think it's a good idea to have lots of functions be polymorphic
 in the record types of their arguments. If that falls out for free (like it
 does both in ORF and Nikita's proposals) that's nice, but I think anonymous
 records should be used sparsely.
 
 To me, anonymous records look a lot like Go's interfaces, which structural
 typing I don't think is a great idea. Go's interfaces give the appearance
 of giving you more polymorphic functions (i.e. functions with arguments of
 type { f :: T, ... }), but you have to express the required laws on these
 record fields purely in terms of comments. With type class-based
 polymorphism you're somewhat more specific and deliberate when you state
 what kind of values your functions are polymorphic over. You don't just say
 this value must support a function f :: T but instead this value must
 support a function f :: T, where the behavior of f is specified by the type
 class it's defined in. I also have extensive experience of duck typing
 from Python and there I think duck typing has not played out well (somewhat
 collaborate by the fact that Python is adding base classes so it's possible
 to talk about the laws I mentioned above.)

I don't think anyone's saying that type classes are going anywhere...?!?

As a counterpoint to duck-typing-in-Python, IME *statically* checked
duck typing works just fine. It's been ages since I programmed in
O'Caml, but I cannot recall a single instance where a problem was caused
by accidentally passing the incorrect wrong duck-ish parameter. (Other
people's experience may differ, of course.)

Do you have concrete experience with Go? I'd of course be skeptical of
taking any lessons from Go in this regard due to the pervasiveness of
the empty interface idiom as a replacement for parametric polymorphism
-- there are usually lots of things that can match the empty interface
-- but it'd be interesting to hear, nonetheless :).

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Deprecating functions

[Bardur Arantsson]

On 2015-01-09 11:25, Herbert Valerio Riedel wrote:
 On 2015-01-09 at 11:18:02 +0100, Jan Stolarek wrote:
 
 The reall 
 question is how to remember that we should remove this at some point?
 
 This affects all exposed libraries; I think it's enough to simply make
 this part of the release-procedure at some point in the release-cycle,
 to actively scan all DEPRECATIONs, and decide for each whether to kill
 them or let them live for another cycle.
 
 It simplifies things though, if it's obvious when a deprecation was
 declared so one doesn't have to `git blame` for it. Many deprecations
 already have a comment attached like deprecated in GHC x.y
 

I think Google's Guava library for Java does a great job at this. In the
documentation is says something like:

   *Deprecated*: Use xxx instead. This class is scheduled for removal in
June 2016.

Then one just needs to add a Remove all scheduled deprecations to the
do-a-release checklist.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs