For the "consistency" you want, `data Oneple a = T a` is the best you can do in Haskell. T(CustId 47) is just one character off from what you actually want to write: (Cust 47). And I presume you want the "extra bottom" that comes with this, as opposed to just treating values as their own one-tuples. I imagine you could write some fancy hack that uses the type system to automatically promote values to Oneples of the given value when an "expected: Oneple Foo, actual: Foo" error occurs. But this would not be very useful in general. An uglier option: type Oneple a = (a, ()) -- Dan Burton On Thu, Aug 15, 2013 at 7:05 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

On 16 August 2013 11:35, AntC wrote:

...

There's an annoying inconsistency:

(CustId 47, CustName "Fred", Gender Male) -- threeple (CustId 47, CustName "Fred) -- twople -- (CustId 47) -- oneple not! () -- nople

(That is, it's annoying if you're trying to make typeclass instances for extensible/contractable tuples. Yes, I know I could use HLists.)

I'm not happy with either approach I've tried:

data Oneple a = Oneple a -- (or newtype) (Oneple $ CustId 47) -- too verbose

type Oneple a = [a] [CustId 47] -- at least looks bracket-y

What do you do?

http://hackage.haskell.org/package/OneTuple :p

If you really wanted some form of parentheses you could possibly use quasiquoting for it...

...

AntC

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

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

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

Brent Yorgey writes:

...

data Oneple a = Oneple a -- (or newtype) (Oneple $ CustId 47) -- too verbose

This is what the OneTuple package is for:

Thank you Brent, and Ivan made the same suggestion. Apart from being more verbose (2 extra chars) than the approach I disliked as being too verbose, does OneTuple have any merit?

Dan Burton danburton.email at gmail.com Fri Aug 16 03:04:14 UTC 2013 claims that "T(CustId 47) is just one character off from what you actually want ..."

(Bare T is very likely to be used already.) But not only do I want to construct Oneples, I also want to pattern match and discriminate on their type in instances: f (T(CustId x)) = ... instance C (Oneple (CustId Int)) ... I'm sensing there must be a need (since OneTuple is claimed to be a solution for it). Would double-parens be too wild an idea?: ... ((CustId 47)) `extend` (CustName "Fred", Gender Male) f ((CustId x)) = ... instance C ((CustId Int)) ... We'd have to avoid the double parens as in: ((meth obj) (double x))

adam vogt writes:

This preprocessor I just threw together doesn't seem to suffers from those issues http://lpaste.net/91967. This kind of approach probably might let you steal T(..) while still allowing `T (..)' to refer to whatever is the original, though I think that would require working with the messier Annotated syntax tree.

wow! Adam, thank you. Even copes with multiple nested parens nested parens instance C ((a, b)) (((( c )))) ... ==> instance C ((a, b)) (OneT.OneTuple (OneT.OneTuple c)) ... AntC

Daniel F writes:

Can you please elaborate why this inconsistency is annoying and what's the use of OneTuple? Genuine question,

Hi Daniel, the main annoyance is the verbosity (of using a data type and constructor), and that it no longer looks like a tuple. The inconsistency is because a one-element tuple is just as cromulent as a n-element, or a zero-element. (And that a one-element tuple is a distinct type from the element on its own/un-tupled.) So if I have instances (as I do) like: instance C (a, b) ... instance C () ... I can't usefully put either of these next two, because they're equiv to the third: instance C (( a )) ... instance C ( a ) ... instance C a ... -- overlaps every instance Similarly for patterns and expressions, the so-called superfluous parens are just stripped away, so equivalent to the bare term. The use of OneTuple is that it comes with all Prelude instances pre- declared (just like all other tuple constructors). I don't see that it has an advantage over declaring your own data type(?) I'd also be interested to know who is using it, and why. What I'm doing is building Type-Indexed Tuples [1] mentioned in HList [2], as an approach to extensible records [3], on the model of Trex [4] -- all of which acknowledge one-element records/rows/tuples. And then I'm using the tuples as a platform for relational algebra [5] with natural Join (and ideas from Tropashko's 'Relational Lattice' [6]). Is there anybody using OneTuple 'in anger'? AntC [1] M. Shields and E.Meijer. Type-indexed rows. In Proceedings of the 28th ACM SIGPLAN-SIGACT symposium on Principles of Programming Languages, pages 261–275. ACMPress, 2001. [2] http://hackage.haskell.org/package/HList [3] http://www.haskell.org/haskellwiki/Extensible_record [4] http://web.cecs.pdx.edu/~mpj/pubs/polyrec.html [5] http://en.wikipedia.org/wiki/Relational_algebra#Natural_join_ [6] http://vadimtropashko.wordpress.com/relational-lattice/

On Fri, Aug 16, 2013 at 5:35 AM, AntC

clear.net.nz> wrote:

There's an annoying inconsistency:     (CustId 47, CustName "Fred", Gender Male)  -- threeple     (CustId 47, CustName "Fred)                -- twople -- (CustId 47) -- oneple not! () -- nople

It seems to me that this is Identity given a different name. A bonus of using Identity is that it won't introduce any new packages to the majority of installations. On 20/08/2013 1:17 PM, "Ivan Lazar Miljenovic" wrote:

On 20 August 2013 11:07, AntC wrote:

...

...

Daniel F writes:

Can you please elaborate why this inconsistency is annoying and what's the use of OneTuple? Genuine question,

Hi Daniel, the main annoyance is the verbosity (of using a data type and constructor), and that it no longer looks like a tuple.

The inconsistency is because a one-element tuple is just as cromulent as a n-element, or a zero-element. (And that a one-element tuple is a distinct type from the element on its own/un-tupled.)

Why is it as "cromulent" (especially as I'm not so sure we could really consider () to be merely a zero-element tuple)?

I can see what you're trying to do here, but for general usage isn't a single element tuple isomorphic to just that element (which is what newtypes are for if you need that distinction)?

...

So if I have instances (as I do) like:

instance C (a, b) ... instance C () ...

I can't usefully put either of these next two, because they're equiv to the third:

instance C (( a )) ... instance C ( a ) ... instance C a ... -- overlaps every instance

Similarly for patterns and expressions, the so-called superfluous parens are just stripped away, so equivalent to the bare term.

The use of OneTuple is that it comes with all Prelude instances pre- declared (just like all other tuple constructors). I don't see that it

has

...

an advantage over declaring your own data type(?) I'd also be interested to know who is using it, and why.

As far as I'm aware, it's just a joke package, but two packages dealing with tuples seem to use it: http://packdeps.haskellers.com/reverse/OneTuple

...

What I'm doing is building Type-Indexed Tuples [1] mentioned in HList

[2],

...

as an approach to extensible records [3], on the model of Trex [4] -- all of which acknowledge one-element records/rows/tuples. And then I'm using the tuples as a platform for relational algebra [5] with natural Join (and ideas from Tropashko's 'Relational Lattice' [6]).

Is there anybody using OneTuple 'in anger'?

AntC

[1] M. Shields and E.Meijer. Type-indexed rows. In Proceedings of the 28th ACM SIGPLAN-SIGACT symposium on Principles of Programming Languages, pages 261–275. ACMPress, 2001. [2] http://hackage.haskell.org/package/HList [3] http://www.haskell.org/haskellwiki/Extensible_record [4] http://web.cecs.pdx.edu/~mpj/pubs/polyrec.html [5] http://en.wikipedia.org/wiki/Relational_algebra#Natural_join_ [6] http://vadimtropashko.wordpress.com/relational-lattice/

...

On Fri, Aug 16, 2013 at 5:35 AM, AntC

clear.net.nz> wrote:

...

There's an annoying inconsistency: (CustId 47, CustName "Fred", Gender Male) -- threeple (CustId 47, CustName "Fred) -- twople -- (CustId 47) -- oneple not! () -- nople

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

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

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

It seems to me that this is Identity given a different name.

Close. But Identity is declared using newtype (just like monad transformers), whereas OneTuple is declared with data (like the other tuples). This may or may not matter, depending on your use case.

On 20/08/2013 1:17 PM, "Ivan Lazar Miljenovic" wrote:

...

On 20 August 2013 11:07, AntC wrote:

...

...

Daniel F writes:

Can you please elaborate why this inconsistency is annoying and what's the use of OneTuple? Genuine question,

Hi Daniel, the main annoyance is the verbosity (of using a data type and constructor), and that it no longer looks like a tuple.

The inconsistency is because a one-element tuple is just as cromulent as a n-element, or a zero-element. (And that a one-element tuple is a distinct type from the element on its own/un-tupled.)

Why is it as "cromulent" (especially as I'm not so sure we could really consider () to be merely a zero-element tuple)?

I can see what you're trying to do here, but for general usage isn't a single element tuple isomorphic to just that element (which is what newtypes are for if you need that distinction)?

...

So if I have instances (as I do) like:

instance C (a, b) ... instance C () ...

I can't usefully put either of these next two, because they're equiv to the third:

instance C (( a )) ... instance C ( a ) ... instance C a ... -- overlaps every instance

Similarly for patterns and expressions, the so-called superfluous parens are just stripped away, so equivalent to the bare term.

The use of OneTuple is that it comes with all Prelude instances pre- declared (just like all other tuple constructors). I don't see that it has an advantage over declaring your own data type(?) I'd also be interested to know who is using it, and why.

As far as I'm aware, it's just a joke package, but two packages dealing with tuples seem to use it: http://packdeps.haskellers.com/reverse/OneTuple

...

What I'm doing is building Type-Indexed Tuples [1] mentioned in HList [2], as an approach to extensible records [3], on the model of Trex [4] -- all of which acknowledge one-element records/rows/tuples. And then I'm using the tuples as a platform for relational algebra [5] with natural Join (and ideas from Tropashko's 'Relational Lattice' [6]).

Is there anybody using OneTuple 'in anger'?

AntC

[1] M. Shields and E.Meijer. Type-indexed rows. In Proceedings of the 28th ACM SIGPLAN-SIGACT symposium on Principles of Programming Languages, pages 261–275. ACMPress, 2001. [2] http://hackage.haskell.org/package/HList [3] http://www.haskell.org/haskellwiki/Extensible_record [4] http://web.cecs.pdx.edu/~mpj/pubs/polyrec.html [5] http://en.wikipedia.org/wiki/Relational_algebra#Natural_join_ [6] http://vadimtropashko.wordpress.com/relational-lattice/

...

On Fri, Aug 16, 2013 at 5:35 AM, AntC

clear.net.nz> wrote:

...

There's an annoying inconsistency: (CustId 47, CustName "Fred", Gender Male) -- threeple (CustId 47, CustName "Fred) -- twople -- (CustId 47) -- oneple not! () -- nople

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

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

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

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

-- Chris Wong, fixpoint conjurer e: lambda.fairy@gmail.com w: http://lfairy.github.io/