Unless it behaves differently in GHC than GHCi, you can still use underscore
prefixed identifiers, provided they are in scope. I only get a type hole
message if the identifier isn't defined anywhere else.
>> let _x = 2
>> _x
2
>> _y
Found hole '_y' with type: t
...
--
View this message in conte
They are described at these two links:
https://www.haskell.org/haskellwiki/GHC/Typed_holes
https://downloads.haskell.org/~ghc/7.8.1-rc1/docs/html/users_guide/typed-holes.html
Essentially, identifiers that are not otherwise in scope and consist of an
underscore or that have a trailing underscore ar
Proposal is up for your viewing pleasure:
http://www.haskell.org/haskellwiki/PermissiveImportsProposal
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758553.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabb
It's occurred to me that a much simpler description of the proposed change
would be automatically lifting *uses* of the explicitly imported variable to
a qualified use, /if/ there was only one explicit import of the identifier.
For instance, with the following import:
import Data.Text.Lazy.IO (put
The current situation could be summed up as requiring some code duplication
when explicitly importing (due to the possibility of one or more redundant
hides), while encouraging a sort of measure-twice-cut-once mentality. Not
suggesting changing the default; I'll have a proposal detailing the exact
wrong way the compiler did, and silent
changes to what is being imported would be bad things. Instead they would
still get an ambiguous occurrence as they do now. It also makes its
behaviour more uniform: only identifiers imported *by name* are auto-hidden.
For a pragma, AutoHidingImports?
hteb
n unrestricted import of a well-known
>> module, it might be easy to assume a certain well-known function comes
>> from
>> there, when in fact it comes from some other module on the other end of
>> the
>> import list.
>>
>> On Oct 18, 2014 6:39 PM, "Joac
echanical when you want
to use most of what a module exports, but not everything. I've described it
as best I can at any rate, so if there's still not enough interest I'll try
to make something of my own to just parse a source file and auto-add the
hiding clauses.
htebalaka wrote
>
bout ambiguity in a very obvious case (a compiler which
> catches many *other* very obvious static code errors), it would
> instead silently accept accept your program under a very implicit
> "DWIM-ish" import rule.
>
> On Sat, Oct 18, 2014 at 1:33 PM, Austin Seipp <
lified 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" <
> goodingm@
> > wrote:
>
>> On 10/17/14 12:32, Ale
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
Yeah, I just realized that would work too. You would still need to do two
passes over the imports, so foo and bar are hidden from anything imported
above A. Though while we're reasoning syntactically, you would also need to
hide them from the Prelude if it was being implicitly imported.
--
View
Well I suppose tooling might need to be aware of the feature depending on
what it does, but I don't see why the code actually typechecking would need
to be dependent on ordering. When I say shadowing I don't mean explicitly
having any explicit import create a new scope, since in that case it would
13 matches
Mail list logo
