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
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 context:
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
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
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
of
the
import list.
On Oct 18, 2014 6:39 PM, Joachim Breitner lt;
mail@
gt;
wrote:
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
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?
htebalaka wrote
At least in the case where something being
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
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 lt;
goodingm@
gt; wrote:
On 10/17/14 12:32, Alexander Berntsen wrote:
On 17/10/14 00:40, Austin Seipp wrote:
Maybe there are some
* 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 lt;
austin@
gt; wrote:
On Sat, Oct 18, 2014 at 1:02 PM, htebalaka lt;
goodingm@
gt; wrote:
On 10/17/14 12
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
Shadowing may have been a poor name on my part
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
12 matches
Mail list logo
