No "fields of ... not initialized" warning with RecordWildCards and Void?
Hi! Would it make sense to suppress the "fields of ... not initialized" when the type of the field is Void, or any other type with no data constructors? As the only way to construct void would be `undefined :: Void`, and the field already is undefined. Regards, -- Markus Läll
On Mon, Nov 01, 2021 at 04:07:02PM +0200, Markus Läll wrote:
Would it make sense to suppress the "fields of ... not initialized" when the type of the field is Void, or any other type with no data constructors? As the only way to construct void would be `undefined :: Void`, and the field already is undefined.
It makes the opposite of sense to me. The warning is there to tell you when you've failed to initialize a field. Whether you *can't* initialise a field because its type has no values makes no difference. You're still not initialising it! I sometimes use a polymorphic field to indicate whether a constructor can be present or not. For example data Expr a = Zero | One | Sum Expr Expr | Product a Expr Expr Now `type ProductExpr = Expr ()` is an `Expr` which might contain `Product`s. `type NoProductExpr = Expr Void` is an `Expr` which cannot because I "can't" write a `Product` constructor for it (at least not without getting a warning). I'm curious: how come you're in the situation where you need to fill in product types with `Void` entries? Tom
Right, I see how you mean. My use of Void is similar to your example: it's a polymorphic field that I don't want to be able to use sometimes, and with Void I thought I wouldn't (at the value level, that is), but as you say I shouldn't be able to construct it either (which I do want to do). In short, what I wanted to remind myself was that this field is empty, and it seemed a better candidate than the unit as the unit I could handle at runtime. But perhaps the correct solution is to refactor the type into separate data types instead. On Mon, Nov 1, 2021 at 4:23 PM Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:
On Mon, Nov 01, 2021 at 04:07:02PM +0200, Markus Läll wrote:
Would it make sense to suppress the "fields of ... not initialized" when the type of the field is Void, or any other type with no data constructors? As the only way to construct void would be `undefined :: Void`, and the field already is undefined.
It makes the opposite of sense to me. The warning is there to tell you when you've failed to initialize a field. Whether you *can't* initialise a field because its type has no values makes no difference. You're still not initialising it!
I sometimes use a polymorphic field to indicate whether a constructor can be present or not. For example
data Expr a = Zero | One | Sum Expr Expr | Product a Expr Expr
Now `type ProductExpr = Expr ()` is an `Expr` which might contain `Product`s. `type NoProductExpr = Expr Void` is an `Expr` which cannot because I "can't" write a `Product` constructor for it (at least not without getting a warning).
I'm curious: how come you're in the situation where you need to fill in product types with `Void` entries?
Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- Markus Läll
Ah, I think you really do want () there then, not Void. Void you *can* use. In fact you can use it to make anything! absurd :: Void -> a () you can't really use because you can't use it to make anything that wasn't there in the first place. Tom On Mon, Nov 01, 2021 at 06:58:16PM +0200, Markus Läll wrote:
My use of Void is similar to your example: it's a polymorphic field that I don't want to be able to use sometimes, and with Void I thought I wouldn't (at the value level, that is), but as you say I shouldn't be able to construct it either (which I do want to do). In short, what I wanted to remind myself was that this field is empty, and it seemed a better candidate than the unit as the unit I could handle at runtime. But perhaps the correct solution is to refactor the type into separate data types instead.
On Mon, Nov 1, 2021 at 4:23 PM Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:
On Mon, Nov 01, 2021 at 04:07:02PM +0200, Markus Läll wrote:
Would it make sense to suppress the "fields of ... not initialized" when the type of the field is Void, or any other type with no data constructors? As the only way to construct void would be `undefined :: Void`, and the field already is undefined.
It makes the opposite of sense to me. The warning is there to tell you when you've failed to initialize a field. Whether you *can't* initialise a field because its type has no values makes no difference. You're still not initialising it!
I sometimes use a polymorphic field to indicate whether a constructor can be present or not. For example
data Expr a = Zero | One | Sum Expr Expr | Product a Expr Expr
Now `type ProductExpr = Expr ()` is an `Expr` which might contain `Product`s. `type NoProductExpr = Expr Void` is an `Expr` which cannot because I "can't" write a `Product` constructor for it (at least not without getting a warning).
I'm curious: how come you're in the situation where you need to fill in product types with `Void` entries?
Got it! I think I've found another way to think about this: - Void is a type-level empty: you can't even construct it - () is a value-level empty: you can construct it but the information content of the value is empty On Mon, Nov 1, 2021 at 7:04 PM Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:
Ah, I think you really do want () there then, not Void. Void you *can* use. In fact you can use it to make anything!
absurd :: Void -> a
() you can't really use because you can't use it to make anything that wasn't there in the first place.
Tom
My use of Void is similar to your example: it's a polymorphic field that I don't want to be able to use sometimes, and with Void I thought I wouldn't (at the value level, that is), but as you say I shouldn't be able to construct it either (which I do want to do). In short, what I wanted to remind myself was that this field is empty, and it seemed a better candidate than the unit as the unit I could handle at runtime. But
the correct solution is to refactor the type into separate data types instead.
On Mon, Nov 1, 2021 at 4:23 PM Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:
On Mon, Nov 01, 2021 at 04:07:02PM +0200, Markus Läll wrote:
Would it make sense to suppress the "fields of ... not initialized" when the type of the field is Void, or any other type with no data constructors? As the only way to construct void would be `undefined :: Void`, and
On Mon, Nov 01, 2021 at 06:58:16PM +0200, Markus Läll wrote: perhaps the
field already is undefined.
It makes the opposite of sense to me. The warning is there to tell you when you've failed to initialize a field. Whether you *can't* initialise a field because its type has no values makes no difference. You're still not initialising it!
I sometimes use a polymorphic field to indicate whether a constructor can be present or not. For example
data Expr a = Zero | One | Sum Expr Expr | Product a Expr Expr
Now `type ProductExpr = Expr ()` is an `Expr` which might contain `Product`s. `type NoProductExpr = Expr Void` is an `Expr` which cannot because I "can't" write a `Product` constructor for it (at least not without getting a warning).
I'm curious: how come you're in the situation where you need to fill in product types with `Void` entries?
Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- Markus Läll
Yes, except you have been constructing a Void value in Haskell (it's just always bottom); that's why you got a compiler warning.
Sent from my phone with K-9 Mail.
On 1 November 2021 17:31:10 UTC, "Markus Läll"
Got it! I think I've found another way to think about this: - Void is a type-level empty: you can't even construct it - () is a value-level empty: you can construct it but the information content of the value is empty
On Mon, Nov 1, 2021 at 7:04 PM Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:
Ah, I think you really do want () there then, not Void. Void you *can* use. In fact you can use it to make anything!
absurd :: Void -> a
() you can't really use because you can't use it to make anything that wasn't there in the first place.
Tom
My use of Void is similar to your example: it's a polymorphic field that I don't want to be able to use sometimes, and with Void I thought I wouldn't (at the value level, that is), but as you say I shouldn't be able to construct it either (which I do want to do). In short, what I wanted to remind myself was that this field is empty, and it seemed a better candidate than the unit as the unit I could handle at runtime. But
the correct solution is to refactor the type into separate data types instead.
On Mon, Nov 1, 2021 at 4:23 PM Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:
On Mon, Nov 01, 2021 at 04:07:02PM +0200, Markus Läll wrote:
Would it make sense to suppress the "fields of ... not initialized" when the type of the field is Void, or any other type with no data constructors? As the only way to construct void would be `undefined :: Void`, and
On Mon, Nov 01, 2021 at 06:58:16PM +0200, Markus Läll wrote: perhaps the
field already is undefined.
It makes the opposite of sense to me. The warning is there to tell you when you've failed to initialize a field. Whether you *can't* initialise a field because its type has no values makes no difference. You're still not initialising it!
I sometimes use a polymorphic field to indicate whether a constructor can be present or not. For example
data Expr a = Zero | One | Sum Expr Expr | Product a Expr Expr
Now `type ProductExpr = Expr ()` is an `Expr` which might contain `Product`s. `type NoProductExpr = Expr Void` is an `Expr` which cannot because I "can't" write a `Product` constructor for it (at least not without getting a warning).
I'm curious: how come you're in the situation where you need to fill in product types with `Void` entries?
Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- Markus Läll
participants (3)
-
Keith -
Markus Läll -
Tom Ellis