Discussion:
Name of 1-Tuple Data Type
Andrew Martin
7 years ago
Permalink
Required background information:
https://ghc.haskell.org/trac/ghc/ticket/14673

GHC has a one-tuple (both a boxed variant and an unboxed variant). The
unboxed variant currently must be fully applied whenever it is used. This
is in stark contrast to all the other n-tuples (n > 1). It stems entirely
from an issue of syntax. The solution decided on is to provide a normal
prefix name for the 1-tuple. The name that GHC uses internally for this
type is `Unit#` (there is also a boxed variant Unit). However, in the
haskell community, the word "unit" already refers to the nullary tuple, not
the unary tuple. So, we're bikeshedding the name.

Here are some possible options:

* Unary (as in unary tuple)
* Single (as in single, double, triple)
* Singleton (as is singleton, doubleton, tripleton)
* Only (
https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html)
* OneTuple (
https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html
)
* Uni (means "one" in latin or greek or something like that)
* Mono (means "one" in latin or greek or something like that)

I would appreciate any feedback on the suggestions I provided or any
additional suggestions for the name. If you have concerns about the feature
itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
focused on just the problem of coming up with a name.
--
-Andrew Thaddeus Martin
David Feuer
7 years ago
Permalink
At present, Unit# is the only way to turn a lifted type into an unlifted
one. Perhaps
Unlift# or Lower# would make sense? The tricky bit is that one could easily
imagine eventually having a version with a strict constructor, in which
case it becomes a bit hard to guess which is which.
Post by Andrew Martin
https://ghc.haskell.org/trac/ghc/ticket/14673
GHC has a one-tuple (both a boxed variant and an unboxed variant). The
unboxed variant currently must be fully applied whenever it is used. This
is
Post by Andrew Martin
in stark contrast to all the other n-tuples (n > 1). It stems entirely
from
...
https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html
)
...
M Farkas-Dyck
7 years ago
Permalink
Identity#
Andrew Martin
7 years ago
Permalink
The problem with using Identity and Identity# is that there's already
something in base named Identity, and since it's a newtype (not a data
type), it has the wrong semantics concerning laziness for this kind of
thing.
Post by M Farkas-Dyck
Identity#
--
-Andrew Thaddeus Martin
Kris Nuttycombe
7 years ago
Permalink
Identity# is my favorite of all those I've seen suggested thus far.
Post by M Farkas-Dyck
Identity#
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Ryan Reich
7 years ago
Permalink
Only has two virtues I can see easily: it's short (shorter than almost all
the others), and it has the same feel as Maybe.

There is also Id, the name of the mathematical function that this type (and
corresponding data) constructor is. Less pithy but even less intrusive.

On Jan 17, 2018 15:47, "Andrew Martin" <***@gmail.com> wrote:

Required background information: https://ghc.haskell.org/trac/ghc/ticket/
14673

GHC has a one-tuple (both a boxed variant and an unboxed variant). The
unboxed variant currently must be fully applied whenever it is used. This
is in stark contrast to all the other n-tuples (n > 1). It stems entirely
from an issue of syntax. The solution decided on is to provide a normal
prefix name for the 1-tuple. The name that GHC uses internally for this
type is `Unit#` (there is also a boxed variant Unit). However, in the
haskell community, the word "unit" already refers to the nullary tuple, not
the unary tuple. So, we're bikeshedding the name.

Here are some possible options:

* Unary (as in unary tuple)
* Single (as in single, double, triple)
* Singleton (as is singleton, doubleton, tripleton)
* Only (https://hackage.haskell.org/package/Only-0.1/docs/Data-
Tuple-Only.html)
* OneTuple (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/
Data-Tuple-OneTuple.html)
* Uni (means "one" in latin or greek or something like that)
* Mono (means "one" in latin or greek or something like that)

I would appreciate any feedback on the suggestions I provided or any
additional suggestions for the name. If you have concerns about the feature
itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
focused on just the problem of coming up with a name.
--
-Andrew Thaddeus Martin
Theodore Lief Gannon
7 years ago
Permalink
I've seen Only in the wild, and it's probably my favorite of the initial
suggestions for the same reasons as Ryan. Mono is my second pick from that
list.

Id is very clean, but I could see pedagogical issues arising from name
confusion. Sing(le(ton)) is a terrible idea for the same reason.

Venturing my own paint swatch: Solo fits in nicely with the established
size-specific names (pair, triple, etc.) and has all the good traits:
short, self-explanatory, nothing with a confusingly similar name (that I
know of).

On Jan 17, 2018 4:35 PM, "Ryan Reich" <***@gmail.com> wrote:

Only has two virtues I can see easily: it's short (shorter than almost all
the others), and it has the same feel as Maybe.

There is also Id, the name of the mathematical function that this type (and
corresponding data) constructor is. Less pithy but even less intrusive.

On Jan 17, 2018 15:47, "Andrew Martin" <***@gmail.com> wrote:

Required background information: https://ghc.haske
ll.org/trac/ghc/ticket/14673

GHC has a one-tuple (both a boxed variant and an unboxed variant). The
unboxed variant currently must be fully applied whenever it is used. This
is in stark contrast to all the other n-tuples (n > 1). It stems entirely
from an issue of syntax. The solution decided on is to provide a normal
prefix name for the 1-tuple. The name that GHC uses internally for this
type is `Unit#` (there is also a boxed variant Unit). However, in the
haskell community, the word "unit" already refers to the nullary tuple, not
the unary tuple. So, we're bikeshedding the name.

Here are some possible options:

* Unary (as in unary tuple)
* Single (as in single, double, triple)
* Singleton (as is singleton, doubleton, tripleton)
* Only (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tupl
e-Only.html)
* OneTuple (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Dat
a-Tuple-OneTuple.html)
* Uni (means "one" in latin or greek or something like that)
* Mono (means "one" in latin or greek or something like that)

I would appreciate any feedback on the suggestions I provided or any
additional suggestions for the name. If you have concerns about the feature
itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
focused on just the problem of coming up with a name.
--
-Andrew Thaddeus Martin
Andreas Abel
7 years ago
Permalink
I deem this feature outside of the mainstream, so it should not occupy a
short nice name.

I suggest UnaryTuple.
...
--
Andreas Abel <>< Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

***@gu.se
http://www.cse.chalmers.se/~abela/
Oleg Grenrus
7 years ago
Permalink
Are we talking about the following:

    {-# LANGUAGE MagicHash, KindSignatures #-}

    import GHC.Exts

    data Unit# (a :: TYPE 'UnliftedRep) = Unit# a

    -- | Also known as:
    --
    --
https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Fusion-Util.html#t:Box
    --
https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html#t:OneTuple
    data Unit  (a :: TYPE 'LiftedRep)   = Unit a

    -- | Also known as
    --
    --
https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Fusion-Util.html#t:Id
    --
https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html
    --
https://hackage.haskell.org/package/generics-sop-0.3.2.0/docs/Generics-SOP-BasicFunctors.html#t:I
    newtype Identity a = Identity a
--
Some libraries (cassava, postgresql-simple - today they use different
`Only`!)
need a wrapper around a type to provide `Field a => Row a` instances,

I haven't needed a `Box` around lifted type, except when putting things
into strict containers. That name weren't proposed, but I don't feel
strongly for or against. Yet, I think `Box#` and `Box` have nice
intuition in them.

- Oleg
...
Andrew Martin
7 years ago
Permalink
It's certainly outside of the mainstream, but it's not going to be part of
the prelude. You'll need to import GHC.Prim or GHC.Exts to get a hold of
it. For this reason, I'm not too worried about stealing a good name.
...
--
-Andrew Thaddeus Martin
Andrew Martin
7 years ago
Permalink
I like Solo. I think it would be a very good name for this for the reasons
you listed.
...
--
-Andrew Thaddeus Martin
Carter Schonwald
7 years ago
Permalink
Unit# seems fine to me, its not gonna be in prelude, its a short name,

i dislike Only because i've only really seen it come up in in DB libraries
:)
...
Andreas Abel
7 years ago
Permalink
-1.

Don't grap any of these nice names for that obscure feature. Take some
ugly name.
...
--
Andreas Abel <>< Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

***@gu.se
http://www.cse.chalmers.se/~abela/
David Feuer
7 years ago
Permalink
I imagine whatever name is chosen will have a # at the end.
...
Henning Thielemann
7 years ago
Permalink
Post by David Feuer
I imagine whatever name is chosen will have a # at the end.
... and you can disambiguate using qualification.
Andreas Abel
7 years ago
Permalink
Post by Henning Thielemann
Post by David Feuer
I imagine whatever name is chosen will have a # at the end.
Then there is no concern.
Post by Henning Thielemann
Post by David Feuer
I imagine whatever name is chosen will have a # at the end.
... and you can disambiguate using qualification.
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
Andreas Abel <>< Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

***@gu.se
http://www.cse.chalmers.se/~abela/
Ivan Lazar Miljenovic
7 years ago
Permalink
-1.
Don't grap any of these nice names for that obscure feature. Take some ugly
name.
It seems like an obscure feature, but something similar has been
re-implemented by a suprising number of libraries (vector,
postgresql-simple, cassava, etc.). Typically when you want to
differentiate a raw value from a (possible singular) collection of
values (e.g. field vs row).
...
--
Ivan Lazar Miljenovic
***@gmail.com
http://IvanMiljenovic.wordpress.com
Mario Blažević
7 years ago
Permalink
Post by Andrew Martin
https://ghc.haskell.org/trac/ghc/ticket/14673
+1 for Only, because it's short and already in use. It's also used by my
own libraries
(https://hackage.haskell.org/package/rank2classes-1.0.1/docs/Rank2.html#t:Only),
so I wouldn't need to rename it. Selfish I know.

Continue reading on narkive:
Loading...