would https://ghc.haskell.org/trac/ghc/ticket/9284 be good candidate for
7.8.4 ?
It looks like its the only forkProcess related bug fix that wasnt merged
into 7.8.3, and impacts OS X
On Mon, Oct 13, 2014 at 12:37 PM, Austin Seipp aus...@well-typed.com
wrote:
Hi *,
After some discussion with
On 10/17/14 12:32, Alexander Berntsen wrote:
On 17/10/14 00:40, Austin Seipp wrote:
Maybe there are some cases today where something like this could
happen, but this seems awfully, awfully implicit and hard-to-follow
as a language feature.
In general I think a program that has
You mention only unqualified imports, but if we do this, it should also
apply to qualified ones:
import qualified Data.List as L
import qualified MyModule as L (isInfixOf)
On Oct 18, 2014 2:02 PM, htebalaka goodi...@gmail.com wrote:
On 10/17/14 12:32, Alexander Berntsen wrote:
On 17/10/14
On Sat, Oct 18, 2014 at 1:02 PM, htebalaka goodi...@gmail.com wrote:
On 10/17/14 12:32, Alexander Berntsen wrote:
On 17/10/14 00:40, Austin Seipp wrote:
Maybe there are some cases today where something like this could
happen, but this seems awfully, awfully implicit and hard-to-follow
as a
And also, the ultimate confusing case: if two modules exported
identifiers with the same name *and* type. At least under the current
scheme, you'd be required to clearly disambiguate them in all cases.
Under the proposed scheme, there's no telling what behavior your
program might have, based
I don't normally import things qualified like that, so it hadn't occurred to
me, but that makes sense. I do want to be clear that this shouldn't be
sensitive to ordering, and it can occur before type checking. You just need
to know what modules are importing which identifiers explicitly, and what
Shadowing may have been a poor name on my part, since that does imply a scope
that is sensitive to order. It's more like import precedence. The explicit
import takes precedence over ones that are being implicitly imported. So in
the Frob/Knob examples the behaviour would be identical in all cases,
I hate to reply three times in a row, but I guess even when adding in that
case it's a little iffy. Currently you could add an explicit import, use the
compiler to track down which cases are ambiguous, and then once you're
confident they're taken care of hide the identifier from the module that
Hello,
Just a heads up, if anyone is playing around with this: I just updated the
plugin interface a bit.
Here are the changes:
- A plugin now gets 3 sets of constraints: given, derived, and wanted
(in that order)
- Plugins are now also presented with dictionary constraints (i.e., you
may
Hi,
Am Samstag, den 18.10.2014, 11:02 -0700 schrieb htebalaka:
I guess my central point is I don't see how anyone can benefit from the
current behaviour. For instance, a simple real world example:
import Prelude
import Data.Text.Lazy.IO (putStrLn)
I find this quite convincing. If I bother
I'm generally in favor of the proposal, but I figured I should mention one
situation when I personally might find this confusing. If the module import
list is very long, and includes an unrestricted import of a well-known
module, it might be easy to assume a certain well-known function comes from
11 matches
Mail list logo
