On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević mblaze...@stilo.com wrote:
On 14-10-19 08:10 AM, Erik Hesselink wrote:
Adding an explicit
import can suddenly cause type errors in completely unrelated places
(when it hides an implicit import and the new function is type
incorrect), or worse,
I'm having a hard time keeping track of what's going on in this discussion.
But, I'm generally in favor of making *some* change along the lines discussed
here, and also in #9702 (https://ghc.haskell.org/trac/ghc/ticket/9702). Could
the proposers of various features perhaps create a wiki page,
Hi Erik,
But right now, we have a useful property that adding imports and code
to a module does not break or change other code in that module. With
this extension, that changes.
So your biggest concern is about silent breakage of code, that suddenly
a different function is used which has the
On 14-10-21 07:14 AM, Erik Hesselink wrote:
On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević mblaze...@stilo.com wrote:
On 14-10-19 08:10 AM, Erik Hesselink wrote:
Adding an explicit
import can suddenly cause type errors in completely unrelated places
(when it hides an implicit import and the
On Tue, Oct 21, 2014 at 4:55 PM, Mario Blažević mblaze...@stilo.com wrote:
On 14-10-21 07:14 AM, Erik Hesselink wrote:
On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević mblaze...@stilo.com
wrote:
No, what I find much worse is a cabal update causing an error in
a
module that was
On October 20, 2014 at 2:35:27 PM, Richard Eisenberg (e...@cis.upenn.edu) wrote:
Having done so, I'm not 100% convinced that this is the right thing to do. I
would love feedback
on my full, concrete proposal available at
https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs
Thanks Iavor, this is really helpful!
If you have a moment to merge Simon's more recent changes on
wip/new-flatten-skolems-Aug14, I'm keen to try out the new
unflattening... or I can have a go at the merge if it would help?
You may be right that flattened constraints are easier to work with in
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
On my OS X, if I load a couple hundred modules into ghci as bytecode,
text entry gets balky and laggy. So e.g. if I hold down a key, the
letters will stream in but have frequent hiccups. This seems to
adversely affect haskeline as well, such that, using vi mode,
sometimes ^[ to move to command
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Postdoctoral position in Functional and Constraint Programming at KU Leuven
The Declarative Languages and Artificial Intelligence (DTAI) group of KU
Leuven (Belgium) invites applicants for a postdoctoral position in the area
of functional and constraint programming. The position revolves around
12 matches
Mail list logo
