-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I like symmetry. +1 from me.
- --
Alexander
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
On 2014-10-26 at 20:28:41 +0100, Tom Murphy wrote:
[...]
I propose that instead, we're able to simply say what we mean:
module Foo hiding (Lockbox(MkLockbox), internalFunction) where
I think its semantics are immediately clear to the reader.
There's a little bit of bikeshedding that
+1 from me
I was looking for the feature a few times.
On 26 October 2014 19:28, Tom Murphy amin...@gmail.com wrote:
(Not to be confused with the hiding import behavior discussion also
going on)
--
Currently, I'm able to write module Foo where to export everything
defined in Foo.
If,
On 2014-10-26 at 20:28:41 +0100, Tom Murphy wrote:
[...]
module Foo hiding (Lockbox(MkLockbox), internalFunction) where
I think its semantics are immediately clear to the reader.
There's a little bit of bikeshedding that needs to happen (e.g. is hiding
(Foo(..)) sufficient to hide the
Hi Tom,
+1
There's a little bit of bikeshedding that needs to happen (e.g. is hiding
(Foo
(..)) sufficient to hide the type Foo and not just its constructors), but are
people +1 on this? I've frequently wanted this behavior.
I would be surprised if 'Foo(..)' would mean in this case
On Mon, Oct 27, 2014 at 2:41 PM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
There's a little bit of bikeshedding that needs to happen (e.g. is hiding
(Foo
(..)) sufficient to hide the type Foo and not just its constructors), but
are
people +1 on this? I've frequently wanted this
El Oct 27, 2014, a las 7:42, Herbert Valerio Riedel h...@gnu.org escribió:
On 2014-10-26 at 20:28:41 +0100, Tom Murphy wrote:
[...]
module Foo hiding (Lockbox(MkLockbox), internalFunction) where
I think its semantics are immediately clear to the reader.
There's a little bit of
No, there's not another way to do this with built-in Nats, and there probably
won't ever be.
There are two advantages to the built-in Nats over hand-rolled ones: 1) Better
syntax / error messages. 2) Built-in Nats are much more efficient than
hand-rolled ones, because the hand-rolled ones are
El Oct 27, 2014, a las 9:57, Erik Hesselink hessel...@gmail.com escribió:
On Mon, Oct 27, 2014 at 2:41 PM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
There's a little bit of bikeshedding that needs to happen (e.g. is hiding
(Foo
(..)) sufficient to hide the type Foo and not just its
No, there's not another way to do this with built-in Nats, and there probably
won't ever be.
I do hope you're wrong.
There are two advantages to the built-in Nats over hand-rolled ones: 1)
Better syntax / error messages. 2) Built-in Nats are much more efficient than
hand-rolled ones,
Your argument here is compelling. I have wanted type-level integers from the
beginning and saw Nats as just a step toward integers. But, of course, this is
silly -- you're right that Nats deserve their own place.
Perhaps make a feature request for this. It may be related to type-level
pattern
+1.
On Sun, Oct 26, 2014 at 3:28 PM, Tom Murphy amin...@gmail.com wrote:
(Not to be confused with the hiding import behavior discussion also
going on)
--
Currently, I'm able to write module Foo where to export everything
defined in Foo.
If, though, I add to the module some definitions
Ok, I've created a ticket https://ghc.haskell.org/trac/ghc/ticket/9731
Unfortunately I don't know enough about ghc internals to try implementing it.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
13 matches
Mail list logo
