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.