a better name for AbsTypeTag

[Eugene Burmako]

After today's discussion at SO I think that the name is not just a bit
unfortunate yet bearable, but actually is actively destructive. Hence
we need a new name. What would you suggest?

For the background behind TypeTag and AbsTypeTag:
http://stackoverflow.com/questions/12093752.

[Josh Suereth]

Is MacroTypeTag too deceptive?

[√iktor Ҡlang]

FullTypeTag?

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Eugene Burmako]

The problem with MacroTypeTag is that it can be used outside macros.

A fact about FullTypeTag that I don't like is that it implies that
it's somehow more full-fledged than TypeTag.

What about ArbTypeTag (from arbitrary)? I agree the name is cryptic,
but at least it's not misleading and it doesn't imply that this type
tag carries more information that a vanilla TypeTag.

On Sep 2, 9:55 pm, √iktor Ҡlang <viktor.kl...@gmail.com> wrote:
> FullTypeTag?
>

> On Sun, Sep 2, 2012 at 9:45 PM, Josh Suereth <joshua.suer...@gmail.com>wrote:
>
> > Is MacroTypeTag too deceptive?

> > On Sep 2, 2012 3:37 PM, "Eugene Burmako" <eugene.burm...@epfl.ch> wrote:
>
> >> After today's discussion at SO I think that the name is not just a bit
> >> unfortunate yet bearable, but actually is actively destructive. Hence
> >> we need a new name. What would you suggest?
>
> >> For the background behind TypeTag and AbsTypeTag:
> >>http://stackoverflow.com/questions/12093752.
>
> --
> Viktor Klang
>
> Akka Tech Lead

> Typesafe <http://www.typesafe.com/> - The software stack for applications
> that scale
>
> Twitter: @viktorklang

[martin odersky]

On Mon, Sep 3, 2012 at 11:13 AM, Eugene Burmako <eugene....@epfl.ch> wrote:

The problem with MacroTypeTag is that it can be used outside macros.

A fact about FullTypeTag that I don't like is that it implies that
it's somehow more full-fledged than TypeTag.

What about ArbTypeTag (from arbitrary)? I agree the name is cryptic,
but at least it's not misleading and it doesn't imply that this type
tag carries more information that a vanilla TypeTag.

PolyTypeTag?

 - Martin

[Eugene Burmako]

I'm not sure. E.g. we can say that "List[_]" is a polymorphic type tag, yet both flavors of type tags for it are applicable to it. Also PolyTypeTag might give an impression that it only work for generics.

[Thomas Matthijs]

Forgive me if this makes no sense at all, since i don't really know
what type tags are, but from the description on that SO post, it seems
like:

TypeTag -> ConcreteTypeTag
AbsTypeTag -> TypeTag

[Miles Sabin]

On Mon, Sep 3, 2012 at 10:25 AM, Eugene Burmako <eugene....@epfl.ch> wrote:
> I'm not sure. E.g. we can say that "List[_]" is a polymorphic type tag, yet
> both flavors of type tags for it are applicable to it. Also PolyTypeTag
> might give an impression that it only work for generics.

FreeTypeTag ("free" as in not yet bound to a specific type)?

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: mi...@milessabin.com
g+: http://www.milessabin.com
http://twitter.com/milessabin

[Rex Kerr]

Is the problem that "Abs" is ambiguous--Abstract?  Absolute?

In that case, I wonder what the words "TypeTag" are actually buying you.  Why not "AbstractTag"?

If the problem instead is that "Abstract" is hard to understand, then I agree with Josh that naming it by its intended use case is most valuable: MacroTypeTag.

If there are many use cases for AbsTypeTag outside of macros (i.e. it's not just possible but desirable), then the TypeTag nomenclature itself needs to be rethought again.  I'm not familiar enough with tags and macros yet to know how this should work out, but I do know that the most common use case should be the shortest and simplest name, and that there should be a really clear distinction between which one should be used in which situation for ordinary situations.

  --Rex

[Eugene Burmako]

ConcreteTypeTag is supposed to be used much more frequently than AbsTypeTag, so I wouldn't like to make it a mouthful.

[Eugene Burmako]

Well, the problem is that AbsTypeTag might also represent a ground type, and in my opinion that doesn't qualify for "free".

[Dave]

Or UniTypeTag from Universal

alternative:

VersTypeTag from Versatile

 

Op maandag 3 september 2012 12:07:41 UTC+2 schreef Eugene Burmako het volgende:

[Eugene Burmako]

I like UniTypeTag.

On Sep 3, 12:14 pm, Dave <dave.mahabiers...@hotmail.com> wrote:
> Or UniTypeTag from Universal
> alternative:
> VersTypeTag from Versatile
>
> Op maandag 3 september 2012 12:07:41 UTC+2 schreef Eugene Burmako het
> volgende:
>
>
>
>
>
>
>
> > Well, the problem is that AbsTypeTag might also represent a ground type,
> > and in my opinion that doesn't qualify for "free".
>

> > On 3 September 2012 11:32, Miles Sabin <mi...@milessabin.com <javascript:>
> > > wrote:
>
> >> On Mon, Sep 3, 2012 at 10:25 AM, Eugene Burmako <eugene....@epfl.ch<javascript:>>

> >> wrote:
> >> > I'm not sure. E.g. we can say that "List[_]" is a polymorphic type tag,
> >> yet
> >> > both flavors of type tags for it are applicable to it. Also PolyTypeTag
> >> > might give an impression that it only work for generics.
>
> >> FreeTypeTag ("free" as in not yet bound to a specific type)?
>
> >> Cheers,
>
> >> Miles
>
> >> --
> >> Miles Sabin
> >> tel: +44 7813 944 528
> >> skype: milessabin

> >> gtalk: mi...@milessabin.com <javascript:>

[Rex Kerr]

Does this solve a problem that Abs doesn't?

Uni could mean Universal, Unified, Unity, Unicorn, etc..

If I were coming into macro-writing and I wanted to do something that I would use TypeTag for in a non-macro, I seriously doubt that I would reach for UniTypeTag.  I am unlikely to be thinking "Oh, Uni means Universal, and I want something Universal now, and I didn't want that before I was writing a macro even though I was using generics".  I would be about as likely to think, "Oh, Abs means Abstract, and I want something abstract now and didn't before even though...".

In fact, arbitrary names or numbers would be less confusing: Tag1 (ArrayTag), Tag2 (ClassTag), Tag3a (TypeTag), Tag3b (AbsTypeTag).  Now I have no preconception about what to use where or why, and I'll have to read the documentation, which will hopefully clearly alert me to the different use cases.

  --Rex

[Josh Suereth]

Uni, of course wins since it implies Unicorn.

Please, send me some unicorn types for this rainbow code!

[Matthew Pocock]

On 3 September 2012 11:06, Eugene Burmako <eugene....@epfl.ch> wrote:

ConcreteTypeTag is supposed to be used much more frequently than AbsTypeTag, so I wouldn't like to make it a mouthful.

We all have IDEs with auto-completion. I'm not saying that we should be creating type names that scroll off the screen, but I'd definitely favour ConcreteTypeTag and AbsoluteTypeTag over shortened versions - they are easier to read, and are at most one ctr-tab longer to type. Why make names of things cryptic if there is no need to?

Matthew

 

On 3 September 2012 11:29, Thomas Matthijs <li...@selckin.be> wrote:

On Sun, Sep 2, 2012 at 9:37 PM, Eugene Burmako <eugene....@epfl.ch> wrote:
> After today's discussion at SO I think that the name is not just a bit
> unfortunate yet bearable, but actually is actively destructive. Hence
> we need a new name. What would you suggest?
>
> For the background behind TypeTag and AbsTypeTag:
> http://stackoverflow.com/questions/12093752.

Forgive me if this makes no sense at all, since i don't really know
what type tags are, but from the description on that SO post, it seems
like:

TypeTag -> ConcreteTypeTag
AbsTypeTag -> TypeTag

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[Christopher Vogt]

Eugene, maybe you can elaborate on the problem you see.

In principle I agree with the current situation, that the most commonly
used tags should be called just TypeTag for ease of writing, even when
your IDE is not at hand.

To brainstorm some more names for AbsTypeTag:

PartialTypeTag
PartiallyKnownTypeTag
PartiallyAbstractTypeTag
IncompleteTypeTag
BestEffortTypeTag

AbstractTypeTag
UnresolvedTypeTag
StaticTypeTag
InconcreteTypeTag

I kinda like PartialTypeTag. It captures the idea, that parts can be
abstract and it is not too long. (Let's *not* shorten it to ParTypeTag :)).

Chris

[Kevin Wright]

DetachedTypeTag, UnfixedTypeTag, UnanchoredTypeTag, UnboundTypeTag, FloatingTypeTag, FreeTypeTag ...

[Kevin Wright]

One more... DisjointTypeTag

[Paul Phillips]

On Mon, Sep 3, 2012 at 6:09 AM, Matthew Pocock <turingate...@gmail.com> wrote:

We all have IDEs with auto-completion.

We don't, and any argument which begins "we all use the same tools" is presumptively invalid.

However you are correct that we should use clear names even if they are longer, with the genuinely universal remedy being "we all have access to type aliases."

[Paul Phillips]

On Mon, Sep 3, 2012 at 2:36 AM, Rex Kerr <ich...@gmail.com> wrote:

Is the problem that "Abs" is ambiguous--Abstract?  Absolute?

It's "a" problem if not "the" problem, at least according to me:

  https://issues.scala-lang.org/browse/SI-5884

[Paul Phillips]

On Mon, Sep 3, 2012 at 6:38 AM, Christopher Vogt <christop...@rwth-aachen.de> wrote:

ParTypeTag

 

Perfect! Then we can add a method "par" to the collections which gets a hold of its Partial Type.

[√iktor Ҡlang]

You forgot the </sarcasm> :(

--

Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Miles Sabin]

On Mon, Sep 3, 2012 at 2:38 PM, Christopher Vogt
<christop...@rwth-aachen.de> wrote:
> Eugene, maybe you can elaborate on the problem you see.
>
> In principle I agree with the current situation, that the most commonly
> used tags should be called just TypeTag for ease of writing, even when
> your IDE is not at hand.
>
> To brainstorm some more names for AbsTypeTag:
>
> PartialTypeTag
> PartiallyKnownTypeTag
> PartiallyAbstractTypeTag
> IncompleteTypeTag
> BestEffortTypeTag
>
> AbstractTypeTag
> UnresolvedTypeTag
> StaticTypeTag
> InconcreteTypeTag

Of these I quite like,

IncompleteTypeTag
UnresolvedTypeTag
PartialTypeTag

In decreasing order of preference.

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: mi...@milessabin.com

[Paul Phillips]

On Mon, Sep 3, 2012 at 7:37 AM, Miles Sabin <mi...@milessabin.com> wrote:

UnresolvedTypeTag

I like this the best, I think.  I also kind of like

  ProtoTypeTag

(What is an abstract type if not a prototype of the type to come?) but it probably errs too much on the side of cute.

[Paul Phillips]

After looking up prototype and finding "one of the ideas or patterns in the divine mind after the likeness of which created things are made" I think I'll cancel my reservations and vote for ProtoTypeTag.

Unless of course YOUR type parameters don't emerge from the "divine mind" in which case okay, we'd better pick something else, and thanks for ruining it with your subdivine notions.

[Kevin Wright]

Based on a thesaurus... I'm thinking that "cute" is good in this context, it's *exactly* where Scala wants to be:

http://thesaurus.com/browse/cute

[martin odersky]

On Mon, Sep 3, 2012 at 4:37 PM, Miles Sabin <mi...@milessabin.com> wrote:

On Mon, Sep 3, 2012 at 2:38 PM, Christopher Vogt
<christop...@rwth-aachen.de> wrote:
> Eugene, maybe you can elaborate on the problem you see.
>
> In principle I agree with the current situation, that the most commonly
> used tags should be called just TypeTag for ease of writing, even when
> your IDE is not at hand.
>
> To brainstorm some more names for AbsTypeTag:
>
> PartialTypeTag
> PartiallyKnownTypeTag
> PartiallyAbstractTypeTag
> IncompleteTypeTag
> BestEffortTypeTag
>
> AbstractTypeTag
> UnresolvedTypeTag
> StaticTypeTag
> InconcreteTypeTag

Of these I quite like,

IncompleteTypeTag
UnresolvedTypeTag
PartialTypeTag

The problem with all these is that they imply that the tag is not complete, which is not necessarily the case. Maybe that's unavoidable, though.

How about

GenericTypeTag?

Cheers

 - Martin

 

[Paul Phillips]

On Mon, Sep 3, 2012 at 8:43 AM, martin odersky <martin....@epfl.ch> wrote:

The problem with all these is that they imply that the tag is not complete, which is not necessarily the case. Maybe that's unavoidable, though.

I think it's unavoidable without a ridiculous name like "PossiblyIncompleteTypeTag" and we should say all complete tags are also incomplete tags which can be made complete by applying the identity.

[Paul Phillips]

On Mon, Sep 3, 2012 at 8:43 AM, martin odersky <martin....@epfl.ch> wrote:

GenericTypeTag

I think the right name will imply, by virtue of its name alone, that it is not usable in the manner in which people expect a fully realized type to be used.  On that point I think "generic" falls short - it would probably send that message to us since we're used to thinking of generic type parameters as unfinished business, but not to most people.

[Paolo G. Giarrusso]

I'm one of those people, so +1.

Il giorno lunedì 3 settembre 2012 17:48:14 UTC+2, Paul Phillips ha scritto:

On Mon, Sep 3, 2012 at 8:43 AM, martin odersky <martin....@epfl.ch> wrote:

The problem with all these is that they imply that the tag is not complete, which is not necessarily the case. Maybe that's unavoidable, though.

I think it's unavoidable without a ridiculous name like "PossiblyIncompleteTypeTag"

The slightly less ridiculous alternatives are BestEffortTypeTag and MaybeUnresolvedTypeTag, which might be short enough. But I'm somewhat cheating, since I use Vim's Ctrl-P autocompletion.
 

Martin's argument can be taken as an argument for having TypeTag and ConcreteTypeTag: those names are surely correct, but we've seen that that's confusing.

Moreover, the standard library has already Function1 and PartialFunction, where a PartialFunction can in fact be total, which is just as confusing (and even more so since PartialFunction <: Function1).

I'd go with IncompleteTypeTag, with a big clarification in the Scaladocs.
 

and we should say all complete tags are also incomplete tags which can be made complete by applying the identity.

 

We have TypeTag <: AbsTypeTag, so a complete tag is already an incomplete tag; not sure how applying the identity completes a tag, though.

Il giorno lunedì 3 settembre 2012 16:37:59 UTC+2, Miles Sabin ha scritto:

Of these I quite like,

IncompleteTypeTag
UnresolvedTypeTag

 

 +1 for those, especially UnresolvedTypeTag. And -1 for ProtoTypeTag for 3 reasons:
* it seems much less intuitive:
def macroImpl[T: c.ProtoTypeTag](c: Context)(a: c.Expr[T]) =...
vs
def macroImpl[T: c.UnresolvedTypeTag](c: Context)(a: c.Expr[T]) =...

* Prototype makes me rather think of C/C++ prototypes, that is, signatures. Probably the same for everybody with enough C/C++ experience.
* My type parameters sure don't come from the divine mind.

[Dave]

Or MetaTypeTag

 

 

Op maandag 3 september 2012 18:04:41 UTC+2 schreef Paolo G. Giarrusso het volgende:

[√iktor Ҡlang]

Or EarlyTypeTag because it includes things that are later erased?

[Patrik Andersson]

Best so far!

[Roland Kuhn]

This is actually the first suggestion which resonated with me. “Generic” on the JVM very much means that a type parameter is involved, which—as far as I understand the issue at hand—is precisely what is going on here. I’m not sufficiently versed in academic computer science to judge whether “generic” has exactly the right meaning, but for a layman it seems to capture the difference quite nicely.

Regards,

Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

[√iktor Ҡlang]

Problem is that it might not involve any abstract type parameter at all, so it's more GenericishTypeTag

 

Regards,

Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

--

Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Paul Phillips]

On Mon, Sep 3, 2012 at 9:50 AM, Roland Kuhn <goo...@rkuhn.info> wrote:

This is actually the first suggestion which resonated with me. “Generic” on the JVM very much means that a type parameter is involved, which—as far as I understand the issue at hand—is precisely what is going on here. I’m not sufficiently versed in academic computer science to judge whether “generic” has exactly the right meaning, but for a layman it seems to capture the difference quite nicely.

It has the right meaning, but it fails to send the right message.  At the user level, a "generic" implementation is usually just as usable as a concrete implementation, possibly having worse performance.

  def f(x: Int): Int = ...

  def f[T](x: T): T = ...

Assuming corresponding implementations, you wouldn't generally think "oh no, don't use the second one when I want the first, that would be a disaster!" However in this case it is actually a disaster - thus the title of my bug report, "implicit disaster".

  https://issues.scala-lang.org/browse/SI-5884

[Som Snytt]

+1 to type aliases and tool catholicity. 

Why not have TypeTag aliased one way for macro implementers, another way for others, similar to what we do for Map.  (Is the consensus that controlling the name Map works well?)

If per SI-6186 there are additional constraints on AbsTypeTag aka TypeTagAbstractable (to resurrect the able suffix), perhaps the two kinds of TypeTag should be sibling types.

The useful type alias for TypeTagAbstractable could go in package object reflect.macros.impl for easy wildcard import.  You could also throw a def foo = language.experimental.macros in there.

[Eugene Burmako]

I already got burned on aliases having c.reify and c.universe.reify doing slightly different things, so to be honest I'm not a big fan of aliases in the api.

[Paul Phillips]

On Mon, Sep 3, 2012 at 1:33 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

I already got burned on aliases having c.reify and c.universe.reify doing slightly different things, so to be honest I'm not a big fan of aliases in the api.

I'm not a big fan of aliases in the api either, but I'm not sure you can pin c.reify and c.universe.reify doing different things on aliases.  You'd have to remind me of what exactly happened there, but as much as I remember there was mass-aliasing plus shadowing going on, and that's going to hurt eventually because it's sure to become inconsistent.  It's not in the same category as "type Foo = LongNameForFoo."

[Eugene Burmako]

The problem was that c.reify was using c.mirror, whereas c.universe.reify was using c.universe.mirror.

What I wanted to say is that if we alias names like "trait Context { type TypeTag = universe.AbstractTypeTag }" (which was suggested above), then we're asking for trouble, because c.TypeTag and c.universe.TypeTag would stand for different things.

[Roland Kuhn]

4 sep 2012 kl. 08:29 skrev Eugene Burmako:

The problem was that c.reify was using c.mirror, whereas c.universe.reify was using c.universe.mirror.

What I wanted to say is that if we alias names like "trait Context { type TypeTag = universe.AbstractTypeTag }" (which was suggested above), then we're asking for trouble, because c.TypeTag and c.universe.TypeTag would stand for different things.

I heartily second that!

On 4 September 2012 08:15, Paul Phillips <pa...@improving.org> wrote:

On Mon, Sep 3, 2012 at 1:33 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

I already got burned on aliases having c.reify and c.universe.reify doing slightly different things, so to be honest I'm not a big fan of aliases in the api.

I'm not a big fan of aliases in the api either, but I'm not sure you can pin c.reify and c.universe.reify doing different things on aliases.  You'd have to remind me of what exactly happened there, but as much as I remember there was mass-aliasing plus shadowing going on, and that's going to hurt eventually because it's sure to become inconsistent.  It's not in the same category as "type Foo = LongNameForFoo."