Lyndon Maydwell | 29 Oct 05:15 2013
Picon

Instance deriving for Void types.

Hi Cafe.


I was wondering if it's possible to have automatic deriving for some classes for the Void type. This would be classes that require a parameter of the type in its functions. This should obviously be trivial as the definition can be undefined since there's no way to supply a value of the type.

I guess the obvious one would be Show.

data Nada deriving Show

{*
instance Show Nada where
  show _ = undefined
*}


Thoughts?
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
AntC | 29 Oct 05:31 2013
Picon

Re: Instance deriving for Void types.

> Lyndon Maydwell <maydwell <at> gmail.com> writes:
> 
> I was wondering if it's possible to have automatic deriving
> for some classes for the Void type. ...
> 

Hi Lyndon, I'm struggling to see any use case for that.

You'd 'achieve' `show (undefined :: Nada)` crashing your program at run-
time; rather than failing to compile (if you didn't have the instance).

Just bite the bullet and give your Void type a constructor.

AntC

> 
> I guess the obvious one would be Show.
> 
> data Nada deriving Show
> 
> {*
> instance Show Nada where
>   show _ = undefined
> *}
> 

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Lyndon Maydwell | 29 Oct 05:40 2013
Picon

Re: Instance deriving for Void types.

The use case I'm interested in is for exploratory programming, I define a type-driven compositional data-flow, and use void types until I'm ready to start filling in the gaps. Some data-dependencies may require class instances, and for this I currently use a stand-alone instance with undefined definitions.

Maybe there's a better way to go about this though? 


On Tue, Oct 29, 2013 at 3:31 PM, AntC <anthony_clayden <at> clear.net.nz> wrote:
> Lyndon Maydwell <maydwell <at> gmail.com> writes:
>
> I was wondering if it's possible to have automatic deriving
> for some classes for the Void type. ...
>

Hi Lyndon, I'm struggling to see any use case for that.

You'd 'achieve' `show (undefined :: Nada)` crashing your program at run-
time; rather than failing to compile (if you didn't have the instance).

Just bite the bullet and give your Void type a constructor.

AntC

>
> I guess the obvious one would be Show.
>
> data Nada deriving Show
>
> {*
> instance Show Nada where
>   show _ = undefined
> *}
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Tom Ellis | 29 Oct 09:18 2013
Picon

Re: Instance deriving for Void types.

On Tue, Oct 29, 2013 at 04:31:49AM +0000, AntC wrote:
> > Lyndon Maydwell <maydwell <at> gmail.com> writes:
> > 
> > I was wondering if it's possible to have automatic deriving
> > for some classes for the Void type. ...
> 
> Hi Lyndon, I'm struggling to see any use case for that.
> 
> You'd 'achieve' `show (undefined :: Nada)` crashing your program at run-
> time; rather than failing to compile (if you didn't have the instance).
> 
> Just bite the bullet and give your Void type a constructor.

It was considered a worthwhile enough idea to add a Show instance to the
"void" package

    http://hackage.haskell.org/package/void-0.6.1/docs/Data-Void.html

(where the instance was written by hand, of course, not derived).

Lyndon: perhaps

    import Data.Void

    newtype Nada = Nada Void deriving (Show)

will suit you use case.

Tom
Lyndon Maydwell | 29 Oct 10:10 2013
Picon

Re: Instance deriving for Void types.

Hey that's a great idea!


On Tue, Oct 29, 2013 at 7:18 PM, Tom Ellis <tom-lists-haskell-cafe-2013 <at> jaguarpaw.co.uk> wrote:
On Tue, Oct 29, 2013 at 04:31:49AM +0000, AntC wrote:
> > Lyndon Maydwell <maydwell <at> gmail.com> writes:
> >
> > I was wondering if it's possible to have automatic deriving
> > for some classes for the Void type. ...
>
> Hi Lyndon, I'm struggling to see any use case for that.
>
> You'd 'achieve' `show (undefined :: Nada)` crashing your program at run-
> time; rather than failing to compile (if you didn't have the instance).
>
> Just bite the bullet and give your Void type a constructor.

It was considered a worthwhile enough idea to add a Show instance to the
"void" package

    http://hackage.haskell.org/package/void-0.6.1/docs/Data-Void.html

(where the instance was written by hand, of course, not derived).

Lyndon: perhaps

    import Data.Void

    newtype Nada = Nada Void deriving (Show)

will suit you use case.

Tom
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Andres Löh | 29 Oct 12:59 2013

Re: Instance deriving for Void types.

Hi.

On Tue, Oct 29, 2013 at 5:15 AM, Lyndon Maydwell <maydwell <at> gmail.com> wrote:

> I was wondering if it's possible to have automatic deriving for some classes
> for the Void type. This would be classes that require a parameter of the
> type in its functions. This should obviously be trivial as the definition
> can be undefined since there's no way to supply a value of the type.
>
> I guess the obvious one would be Show.
>
> data Nada deriving Show
>
> {*
> instance Show Nada where
>   show _ = undefined
> *}

This actually works with StandaloneDeriving:

{-# LANGUAGE StandaloneDeriving #-}

data Nada
deriving instance Show Nada
deriving instance Eq Nada
deriving instance Ord Nada

And I agree, all of these are useful, in particular if Nada is used as
an argument to a parameterized datatype. Trying to derive Read
triggers a compiler bug with 7.6.3, but this seems to be fixed in
HEAD.

Cheers,
  Andres

--

-- 
Andres Löh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com

Gmane