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
t
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 bot
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
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 was
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 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
m
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 solely
On Sat, Oct 18, 2014 at 1:02 PM, htebalaka 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 langua
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" wrote:
> On 10/17/14 12:32, Alexander Berntsen wrote:
> > On 17/10/14 00:40, Austin Sei
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 tha
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
wrote:
> Hi *,
>
> After some discussion with Simon & Mikolaj toda
11 matches
Mail list logo
