Re: "Excuse me, I think this i my stop..." - Resigning from the Platform
Thanks Mark for all your work over the years! Haskell has the adoption it does today in no small part because of your work in making sure it has been consistently easy to install over a range of systems. You’ve put many years and long hours into the work you’ve done as release manager, and we all appreciate it. I certainly suspect the applicatipocalypse is less around-the-bend than you perhaps prophesy (sorry, couldn’t resist). But as they say, horses for courses. I look forward to catching up with you at those meetups and conferences. Everyone else: I’m happy to step in for the immediate time being as release manager to bring to completion the minimal-platform-with-cabal-and-stack plans (aka “Improving the Get Haskell Experience” proposal). I’ve already started to do so a very tiny bit, helping with a new OS X release to help with compatibility with El Capitan. I also want to note that lots of contributions lately have been coming courtesy of Randy Polen and Erik Rantapaa in particular, so we have some great resources to build on. Especially medium term and long term more volunteers will be very welcome (I certainly can’t imagine remaining “Mr. Platform” for as many tireless years as Mark has). A fair amount of the work I plan to spend on platform stuff in the immediate future will be to take the good work Mark has done in making easier the platform build and release process and further document it. The end goal should be that, at least for the foreseeable future, the release manager job should become straightforward and demystified enough that passing the baton becomes easier yet. If you have experience with installers in either the Windows or Mac world and would like to get involved (maybe just as a voice of experience and wisdom) please reach out to me and let me know. Alternately, if you have a friend with such experience, and you think you could convince them to lend a hand, perhaps suggest to them that they reach out to me :-P. Also, if you have either a range of boxes (or hardware with images of different flavors of systems) and some time to act as a tester — please reach out as well. A designated team of installer-testers would be a good thing as well. Best, Gershom On October 12, 2015 at 11:09:12 PM, Mark Lentczner (mark.lentcz...@gmail.com) wrote: > I think this is the right time for me to exit: > > The truth is, I still can't bring myself to use a version of Haskell post > the Foldable-Traversable-aPocalypse, let alone some future Haskell after > the changes now in the works. My personal machines are all still 7.8. My > personal projects are all pre-FTP. The Haskell I love to code in, the > Haskell I'm passionate about, the Haskell I've advocated for real world > use, and the Haskell I like to teach, is 7.8, pre-FTP. > > It's not that I'm dead set against change and evolution in a language, or > even breaking changes. But FTP and beyond are changes that have lost the > balance that Haskell had between abstraction and clarity, between elaborate > and practical engineering. I don't see any restraint going forward, so I'm > getting off the train. > > This puts me in an odd position with respect to Haskell Platform: I find > myself building the Platform for a version of Haskell that I don't use. > This isn't healthy for either the Platform or me. Hence, I'm resigning as > release manager. > > I am sad because I believed that Haskell's path to much wider adoption was > within reach. Now, especially with the ramping up of the Haskell Prime > committee, which seems preordained to codify FTP and beyond into standard, > we are approaching our Algol 68 moment: Building a major language revision > with less opportunity than it's predecessor. > > I'll still see you 'round at meet-ups and conferences. I'll just be coding > with an older accent. > > - Mark "mzero" Lentczner > ___ > Libraries mailing list > librar...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
"Excuse me, I think this i my stop..." - Resigning from the Platform
I think this is the right time for me to exit: The truth is, I still can't bring myself to use a version of Haskell post the Foldable-Traversable-aPocalypse, let alone some future Haskell after the changes now in the works. My personal machines are all still 7.8. My personal projects are all pre-FTP. The Haskell I love to code in, the Haskell I'm passionate about, the Haskell I've advocated for real world use, and the Haskell I like to teach, is 7.8, pre-FTP. It's not that I'm dead set against change and evolution in a language, or even breaking changes. But FTP and beyond are changes that have lost the balance that Haskell had between abstraction and clarity, between elaborate and practical engineering. I don't see any restraint going forward, so I'm getting off the train. This puts me in an odd position with respect to Haskell Platform: I find myself building the Platform for a version of Haskell that I don't use. This isn't healthy for either the Platform or me. Hence, I'm resigning as release manager. I am sad because I believed that Haskell's path to much wider adoption was within reach. Now, especially with the ramping up of the Haskell Prime committee, which seems preordained to codify FTP and beyond into standard, we are approaching our Algol 68 moment: Building a major language revision with less opportunity than it's predecessor. I'll still see you 'round at meet-ups and conferences. I'll just be coding with an older accent. - Mark "mzero" Lentczner ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args
Hi, As a GHC API user, I would like to run GHC’s strictness and demand analysis pass, but I don’t want any worker/wrappers. My specific use-case is to generate digital circuits from Haskell code, where I’ve yet to encounter any benefit from worker/wrappers: the generated circuits do not get any smaller or faster. They do however induce longer compilation times for my compiler. I still want to have GHC’s strictness and demand analysis, because, if I understand correctly, the demand and strictness annotations are needed by GHC’s dead code analysis (and other optimisations) which is beneficial for my use case. Looking through DynFlags, I encountered the ‘maxWorkerArgs’ field, which is controlled by ‘-fmax-worker-args’. The user guide says the following: "If a worker has that many arguments, none will be unpacked anymore (default: 10)” I don’t know exactly what this means, but I was hoping that if I would set that number to 0 (zero), no worker/wrapper pairs would be created. Is that correct? The reason that I’m asking is because -fmax-worker-args is basically dead code. The ‘maxWorkerArgs’ field of DynFlags is not used anywhere. If setting ‘-fmax-worker-args’ to zero does indeed prevent any worker/wrappers from being generated, should I reimplement the flag and submit it as a patch? Or, is it preferable to simply remove ‘-fmax-worker-args’ (given that it doesn’t do anything right now), and create a new flag, ‘-fno-worker-wrapper’, that simply disables the creation of worker/wrapper pairs everywhere? Regards, Christiaan ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Applicative Comprehensions
Paralell comprehension syntax will be confusing.
If user have both MonadComprehensions and ApplicativeDo enabled, it makes total
sense to desugar monad comprehensions into Applicative expression when it’s
possible, and into Monadic otherwise. I’m actually a bit surprised if it’s not
already a case.
- Oleg
> On 12 Oct 2015, at 10:14, Roman Cheplyaka wrote:
>
> I like this idea because having the pure function call at the beginning
> (rather than at the end, as with do-notation) is more consistent with the
> original <$>,<*>-notation.
>
> It only slightly bothers me that the bracket notation in this form has
> nothing to do with lists, so that may be a bit confusing. But this is already
> true for monad comprehensions.
>
> It might make more sense to reuse the parallel list comprehension syntax
> (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax-extns.html#parallel-list-comprehensions),
> as applicatives are "parallel". So, [ i + 2*j | i <- rows | j <- cols ].
>
> On 10/12/2015 11:09 AM, David A Roberts wrote:
>> Hi,
>>
>> I raised this question on #haskell, and was advised that this was
>> probably the best place to discuss.
>>
>> I see that Applicative Do is scheduled for GHC 8.0 [1], and was hoping
>> that this might also enable support for Applicative Comprehensions [2].
>> Is this likely to be the case? If not, would it be difficult to extend
>> the support for Applicative Do to also handle comprehensions? I'm
>> willing to submit patches if necessary, but I'm not at all familiar with
>> GHC internals, so would need some guidance.
>>
>> I understand that comprehensions tend not to be used much in idiomatic
>> Haskell, but I find them to be useful for implementing DSLs, so would
>> really like to see this be supported. For example, a matrix could be
>> written in a familiar notation:
>>
>>> [ i + 2*j | i <- rows, j <- cols ]
>>
>> which is a little more readable (to those not familiar with Haskell) than
>>
>>> (\i j -> i + 2*j) <$> row <*> cols
>>
>> or
>>
>>> do { i <- rows; j <- cols; return (i + 2*j) }
>>
>> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#LandedinHEAD
>> [2]
>> https://ghc.haskell.org/trac/ghc/wiki/GeneralizedMonadComprehensions#Applicativefunctor
>>
>> --
>> David A Roberts
>> https://davidar.io
>>
>>
>> ___
>> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Applicative Comprehensions
I like this idea because having the pure function call at the beginning (rather
than at the end, as with do-notation) is more consistent with the original
<$>,<*>-notation.
It only slightly bothers me that the bracket notation in this form has nothing
to do with lists, so that may be a bit confusing. But this is already true for
monad comprehensions.
It might make more sense to reuse the parallel list comprehension syntax
(https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax-extns.html#parallel-list-comprehensions),
as applicatives are "parallel". So, [ i + 2*j | i <- rows | j <- cols ].
On 10/12/2015 11:09 AM, David A Roberts wrote:
> Hi,
>
> I raised this question on #haskell, and was advised that this was
> probably the best place to discuss.
>
> I see that Applicative Do is scheduled for GHC 8.0 [1], and was hoping
> that this might also enable support for Applicative Comprehensions [2].
> Is this likely to be the case? If not, would it be difficult to extend
> the support for Applicative Do to also handle comprehensions? I'm
> willing to submit patches if necessary, but I'm not at all familiar with
> GHC internals, so would need some guidance.
>
> I understand that comprehensions tend not to be used much in idiomatic
> Haskell, but I find them to be useful for implementing DSLs, so would
> really like to see this be supported. For example, a matrix could be
> written in a familiar notation:
>
>> [ i + 2*j | i <- rows, j <- cols ]
>
> which is a little more readable (to those not familiar with Haskell) than
>
>> (\i j -> i + 2*j) <$> row <*> cols
>
> or
>
>> do { i <- rows; j <- cols; return (i + 2*j) }
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#LandedinHEAD
> [2]
> https://ghc.haskell.org/trac/ghc/wiki/GeneralizedMonadComprehensions#Applicativefunctor
>
> --
> David A Roberts
> https://davidar.io
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
signature.asc
Description: OpenPGP digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Applicative Comprehensions
Sounds reasonable to me. Do-notation and comprehension notation are really
just syntactic sugar for the same thing.
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David A
Roberts
Sent: 12 October 2015 09:10
To: ghc-devs@haskell.org
Subject: Applicative Comprehensions
Hi,
I raised this question on #haskell, and was advised that this was probably the
best place to discuss.
I see that Applicative Do is scheduled for GHC 8.0 [1], and was hoping that
this might also enable support for Applicative Comprehensions [2]. Is this
likely to be the case? If not, would it be difficult to extend the support for
Applicative Do to also handle comprehensions? I'm willing to submit patches if
necessary, but I'm not at all familiar with GHC internals, so would need some
guidance.
I understand that comprehensions tend not to be used much in idiomatic Haskell,
but I find them to be useful for implementing DSLs, so would really like to see
this be supported. For example, a matrix could be written in a familiar
notation:
> [ i + 2*j | i <- rows, j <- cols ]
which is a little more readable (to those not familiar with Haskell) than
> (\i j -> i + 2*j) <$> row <*> cols
or
> do { i <- rows; j <- cols; return (i + 2*j) }
[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#LandedinHEAD
[2]
https://ghc.haskell.org/trac/ghc/wiki/GeneralizedMonadComprehensions#Applicativefunctor
--
David A Roberts
https://davidar.io
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Applicative Comprehensions
Hi, Am Montag, den 12.10.2015, 08:09 + schrieb David A Roberts: > I understand that comprehensions tend not to be used much in > idiomatic Haskell, quite contrary! I use them extensively in real-world-projects, and I claim to write idomatic code :-) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Applicative Comprehensions
Hi,
I raised this question on #haskell, and was advised that this was probably
the best place to discuss.
I see that Applicative Do is scheduled for GHC 8.0 [1], and was hoping that
this might also enable support for Applicative Comprehensions [2]. Is this
likely to be the case? If not, would it be difficult to extend the support
for Applicative Do to also handle comprehensions? I'm willing to submit
patches if necessary, but I'm not at all familiar with GHC internals, so
would need some guidance.
I understand that comprehensions tend not to be used much in idiomatic
Haskell, but I find them to be useful for implementing DSLs, so would
really like to see this be supported. For example, a matrix could be
written in a familiar notation:
> [ i + 2*j | i <- rows, j <- cols ]
which is a little more readable (to those not familiar with Haskell) than
> (\i j -> i + 2*j) <$> row <*> cols
or
> do { i <- rows; j <- cols; return (i + 2*j) }
[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#LandedinHEAD
[2]
https://ghc.haskell.org/trac/ghc/wiki/GeneralizedMonadComprehensions#Applicativefunctor
--
David A Roberts
https://davidar.io
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
