Poll on how to name manifest replacements

[martin odersky]

Scala 2.10 will introduce a new set of types that will eventually replace manifests. The new-style manifests fulfill similar roles to what Manifest/ClassManifest/OptManifest do now, yet are cleanly integrated with reflection. It was not possible to do that with the old style of manifests, and neither was it possible to migrate manifests safely to the new style. That's why for 2.10, old-style manifests will exists together with the new types, but will be deprecated   The compiler will in any case happily infer either type for you, depending on what you specified. 

There's still a question on what the new types should be named. Just to set the context, we picked "Manifest" as a name before because it can be used as an adjective. So the typical usage as a context bound, as in

  [T: Manifest]

reads will, because it suggests that "Manifest" is a property of the type "T". "ClassManifest" works slightly less well, though. But anyway, these names are no longer available, and we need new ones.

I wanted to get your opinion on what naming scheme you prefer. There are essentially three variants. In current trunk, we use the following names: 

Alternative 1:

[T: TypeTag]   Instances of type T come with a descriptor that describes their whole type.  This is analogous to Manifest in 2.8/2.9.

[T: ClassTag]   Instances of type T come with a descriptor that describes their erasure in a top-level Java class. This is analogous to ClassManifest in 2.8/2.9.

[T: ArrayTag]   It is possible to form arrays with instances of type T as elements. This is the same as ClassManifest in 2.8/2.9; it has been split off in 2.10 because some platforms (e.g. GWT) do not know Java classes, yet can still form arrays.

All of that is more or less fine, except that none of the names above are adjectives. So the context bounds do not read very well. I also don't like the slightly different signification of ArrayTag from the others. TypeTag, ClassTag tell you about descriptors that come with the type, whereas ArrayTag means that you can form an array from elements of the type. Prompted by Simon PJ's Scala Days talk, where he showed "Typeable" as a name for something in Haskell that's similar to a manifest, I started to think of an alternative:

Alternative 2a:

[T: Typeable]    Instances of type T come with a descriptor that describes their whole type. 

[T: Classable]  Instances of type T come with a descriptor that describes their erasure in a top-level Java class.

[T: Arrayable]   Instances of type T can be aligned in an array.

I personally like that naming scheme because they are all words in the english dictionary and have the right connotations. But "classable" and "arrayable" are pretty uncommon english words and native speakers such as Miles found their use "ghastly" ;-). I believe in particular "classable" is contentious as a term. So to be slightly less contentions we could also do 

Alternative 2b:

[T: Typeable]    

[T: Classifiable]  

[T: Arrayable] 

"Classifiable" is a slightly longer word than "classable" and to my eyes not as directly connected with the meaning of runtime class. But but it's more familiar.

So, what do you think? I am trying to get some feedback on this, in particular from native english speakers (but not only from them). You can simply respond with 1/2a/2b depending on which option you like best, or you can argue for one of the options, or maybe even propose yet another naming scheme (although we went through this already and I really would like to keep the current discussion focussed).

Cheers

 - Martin

 

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Eugene Burmako]

One thing we should also evaluate is naming of incantations to summon these descriptors, e.g. typeTag[T] or typeable[T].

In this light I tend to like 1 better, because, imho, incantations for 1 sound a bit better than for 2.

[√iktor Ҡlang]

I'd prefer something like:

Reified[T]

Reified[Class[T]]

Reified[Array[T]]

* puts down the paintbrush *

Cheers,

√

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[√iktor Ҡlang]

On Sun, May 20, 2012 at 6:56 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

I'd prefer something like:

Reified[T]

Reified[Class[T]]

Reified[Array[T]]

Ack, lost the bestest bits!

TypeOf[T] extends Reified[T]

ClassOf[T] extends Reified[Class[T]]

ArrayOf[T] extends Reified[Array[T]]

[Eugene Burmako]

Having classOf and typeOf as incantations totally rocks!!

[Eugene Burmako]

Even though arrayOf does not feel like an excellent name for an implicit summoning incantation, on a second thought, we dont need an incantation for ArrayTag per se. We only need an array creator, and arrayOf[T](dim) looks perfect for the job.

But typeOf[T]... Wow, just wow. Super duper cool!!

[martin odersky]

On Sun, May 20, 2012 at 6:28 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

One thing we should also evaluate is naming of incantations to summon these descriptors, e.g. typeTag[T] or typeable[T].

In this light I tend to like 1 better, because, imho, incantations for 1 sound a bit better than for 2.

 

Let's not concentrate on incantations. They are for the specialist and a specialist will write whatever is required, including implicitly[Typeable[T]], which is probably perfectly fine. What matters is all the user code that now decorates types with ClassManifest or Manifest and will have to decorate types with the new names. 

So, everyone please, coach the discussion in terms of context bounds, and ignore the rest. Otherwise we will have immediately derailed the discussion.

 - Martin

[√iktor Ҡlang]

On Sun, May 20, 2012 at 7:19 PM, martin odersky <martin....@epfl.ch> wrote:

On Sun, May 20, 2012 at 6:28 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

One thing we should also evaluate is naming of incantations to summon these descriptors, e.g. typeTag[T] or typeable[T].

In this light I tend to like 1 better, because, imho, incantations for 1 sound a bit better than for 2.

 

Let's not concentrate on incantations. They are for the specialist and a specialist will write whatever is required, including implicitly[Typeable[T]], which is probably perfectly fine. What matters is all the user code that now decorates types with ClassManifest or Manifest and will have to decorate types with the new names. 

def foo[A : ArrayOf] == implicitly[ArrayOf[A]] == arrayOf[A](dim) == Array[A](dim) (could be deprecated)

def foo[C : ClassOf] == implicitly[ClassOf[C]] == classOf[C] (with an implicit from classOf[C] => Class[C])

def foo[T : TypeOf] == implicitly[TypeOf[T]] == typeOf[T]

[martin odersky]

On Sun, May 20, 2012 at 7:23 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Sun, May 20, 2012 at 7:19 PM, martin odersky <martin....@epfl.ch> wrote:

On Sun, May 20, 2012 at 6:28 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

One thing we should also evaluate is naming of incantations to summon these descriptors, e.g. typeTag[T] or typeable[T].

In this light I tend to like 1 better, because, imho, incantations for 1 sound a bit better than for 2.

 

Let's not concentrate on incantations. They are for the specialist and a specialist will write whatever is required, including implicitly[Typeable[T]], which is probably perfectly fine. What matters is all the user code that now decorates types with ClassManifest or Manifest and will have to decorate types with the new names. 

def foo[A : ArrayOf] == implicitly[ArrayOf[A]] == arrayOf[A](dim) == Array[A](dim) (could be deprecated)

def foo[C : ClassOf] == implicitly[ClassOf[C]] == classOf[C] (with an implicit from classOf[C] => Class[C])

def foo[T : TypeOf] == implicitly[TypeOf[T]] == typeOf[T]

 

Yes, I see. That means you are stuck with the weird context bounds, unfortunately.

- Martin

[Rex Kerr]

I prefer 2a.

If "Classable" is too unpalatable, I suggest instead
  TypeKnown
  ClassKnown
  ArrayKnown
as a slightly longer but much more informative version of "Tag".  Who knows what a tag does?  But with Known, you have a pretty good idea from glancing what might be going on.  Likewise with -Info.  I really think Tag is a bad idea.  I also think "Classifiable" is a bad idea, because it gives exactly the wrong impression: yes, it is an English word, but it is used here _contrary to_ its normal meaning (the normal meaning is not "has erasure-level class information") and therefore I would argue is more harmful than helpful.

I _still_ (mildly) prefer 2a, but I like -Known or -Info much better than I like -Tag.  (More bike shed opportunities: TypeKnown or KnownType?)

  --Rex

[Dave]

I would use Reifiable.

> [T: TypeReifiable]
> [T: ClassReifiable]
> [T: ArrayReifiable]

Reifiable is 5 characters longer than -able, but it is a normal
English adjective and tells what it does.

PS: I am not a native English speaker.

> Prof., EPFL <http://www.epfl.ch> and Chairman, Typesafe<http://www.typesafe.com>

[Jan Vanek]

TypeBound

ClassBound

ArrayBound

Otherwise 2a. Very much against 2b.

Regards,

Jan

[Eugene Vigdorchik]

A combination of the propoed ideas:

-TypeKnown
-ClassKnown
-Arrayable

I feel the last one is really different in semantics, so having a
different name style is justified.

Eugene.

[Simon Ochsenreither]

I strongly prefer alternative 1. Imho it is a nice compromise between straightforwardness, conciseness, and accessibility for both developers and compiler hackers.
After developing on 2.10 for a while now I even prefer the names to Manifest. Manifest is "obvious" for language developers, but not for users.
The meaning of <Foo>Tag is pretty much understandable without looking at documentation at all.

If every Scala user came from Haskell, Typeable would be acceptable, but that's a) not the case and b) both "Classifiable" and "Classable" are horrible.

In general I would prefer two short words to one long word.

If everything fails, I would suggest "TagForAll", "TagForClass" and "TagForArray" which I think is definitely worse than 1, but better than 2a/2b.

Mhhh Token? "TypeToken", "ClassToken", "ArrayToken"? I would put behind 1 but ahead of "TagForFoo".

[Dave]

What about:

> [T: TypeReified]
> [T: ClassReified]
> [T: ArrayReified]

Reified is ahorter than Reifiable and it's an adjective too.

On 20 mei, 19:26, martin odersky <martin.oder...@epfl.ch> wrote:
> On Sun, May 20, 2012 at 7:23 PM, √iktor Ҡlang <viktor.kl...@gmail.com>wrote:
>
>
>
>
>
>
>
> > On Sun, May 20, 2012 at 7:19 PM, martin odersky <martin.oder...@epfl.ch>wrote:

>
> >> On Sun, May 20, 2012 at 6:28 PM, Eugene Burmako <eugene.burm...@epfl.ch>wrote:
>
> >>> One thing we should also evaluate is naming of incantations to summon
> >>> these descriptors, e.g. typeTag[T] or typeable[T].
>
> >>> In this light I tend to like 1 better, because, imho, incantations for 1
> >>> sound a bit better than for 2.
>
> >> Let's not concentrate on incantations. They are for the specialist and a
> >> specialist will write whatever is required, including
> >> implicitly[Typeable[T]], which is probably perfectly fine. What matters is
> >> all the user code that now decorates types with ClassManifest or Manifest
> >> and will have to decorate types with the new names.
>
> > def foo[A : ArrayOf] == implicitly[ArrayOf[A]] == arrayOf[A](dim) ==
> > Array[A](dim) (could be deprecated)
> > def foo[C : ClassOf] == implicitly[ClassOf[C]] == classOf[C] (with an
> > implicit from classOf[C] => Class[C])
> > def foo[T : TypeOf] == implicitly[TypeOf[T]] == typeOf[T]
>
> Yes, I see. That means you are stuck with the weird context bounds,
> unfortunately.
>

> - Martin- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

[Matthew Pocock]

At the risk of opening old wounds, what do these three types mean? Think of a normal user hitting these things for the first time. They are most likely simply calling into some existing library that requires instances of these types. They certainly are not developing cunning things that actually use these types to do interesting things. To this consumer, what do the types signify? For example, I may be wrong but at the moment I understand ArrayReified (or whatever it is called) to mean something like this:

In `ar: ArrayReified[T]`, the value `ar` is evidence that it is possible to construct an `Array[T]`. Use `...` to construct a new `Array[T]` from `ar`.

From this description, a name like ArrayElement[T] or Arrayable[T] would seem to make sense. Is my description of the type technically correct? Is there anything major about ArrayReified that a noob needs to know to be able to use it which I have missed off? Do we have similarly succinct descriptions of the other two?

Matthew

--

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

[Francois]

On 20/05/2012 18:21, martin odersky wrote:
> Scala 2.10 will introduce a new set of types that will eventually

> replace manifests. [...]
>
> Alternative 1:
> [T: TypeTag] ...
> [T: ClassTag] ...
> [T: ArrayTag] ...
>
> [...]
> Alternative 2a:
> [T: Typeable] ...
> [T: Classable] ...
> [T: Arrayable] ...

> [...]

> Alternative 2b:
> [T: Typeable]
> [T: Classifiable]
> [T: Arrayable]
>

I'm really against 2b, because that cause an unnecessary form for Class
(if such a difference have to happen, it should be for Array).
I'm not really for 2a (I'm clearly not an English native speaker, but
that feel weird). And for 1/, well tag does not bring a lot of information.

So I'm against 2b, and perhaps 1 and then 2a.

Just to be sure, that alternative must have been avoided for some
obvious reasons (name overloading ?), but I don't find it in the archive
of the ml:

[T: TypeInfo] ...
[T: ClassInfo] ...
[T: ArrayInfo] ...

Or even a {Type,Class,Array}Maker (or Builder) ?

--
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

[martin odersky]

But neither is an adjective. Cheers -- Martin

[√iktor Ҡlang]

Typical

Classical

Arrayical ;D

[Rex Kerr]

There are lots of adjective suffixes one could use:
  Typish   // Typeish?
  Classish
  Arrayish

  Typing
  Classing
  Arraying

  Typeful
  Classful
  Arrayful

  Typey
  Classy
  Arrayey

  Typesque
  Classesque
  Arrayesque

And of course the good old retreat to past tense along with English allowing pretty much any noun to function as a modifier for another noun:

  Typed
  Classed
  Arrayed

I assume these were already considered and -able was chosen as the best.  (Personally I think the -ish or -ing forms are nicer linguistically than the -able forms, but the -able is most accurate.  The -ing and -ed forms are the only ones my spellchecker tolerates.)

--Rex

[Josh Suereth]

Why don't we use adverbs and change context bounds to be prefix?

Typely T

Arrayly T

Classly T

My, that's quite the Classly type you have there!  Might I offer you a Typely substitute?

OR, instead, let's look at how things read:

T: WithClass

T: WithArrayBuilder

T: WithType

Phrasing prepositionally, 

seeming better, 

dangling participles?

[√iktor Ҡlang]

How about:

TypeDesc

ClassDesc

ArrayDesc

[Josh Suereth]

Of the original proposal I like *Tag best.

[Dave]

I don't think a noob has to know about the implementation details (by
Java classes or macros) and what parts are actually concretized in
order to use a concretized type.

To use
[T: ArrayReified]

is simply (same as Manifest or ConcreteTypeTag, make the first
character lowercase):

arrayReified[T] or arrayReified[T].erasure

and then you can use it as if there were really reified generics and
do reflection

>On 20 mei, 21:29, Matthew Pocock <turingatemyhams...@gmail.com> wrote:
> At the risk of opening old wounds, what do these three types mean? Think of
> a normal user hitting these things for the first time. They are most likely
> simply calling into some existing library that requires instances of these
> types. They certainly are not developing cunning things that actually use
> these types to do interesting things. To this consumer, what do the types
> signify? For example, I may be wrong but at the moment I understand
> ArrayReified (or whatever it is called) to mean something like this:
>
> In `ar: ArrayReified[T]`, the value `ar` is evidence that it is possible to
> construct an `Array[T]`. Use `...` to construct a new `Array[T]` from `ar`.
>

It does but I don't think that way every time I use a context bound
and I think it is not necessary.
With context bound e.g. A:B I think: A has a B so in this case T has
an ArrayReified

> From this description, a name like ArrayElement[T] or Arrayable[T] would

The first is a noun and it should be an adjective (Simon PJ)
and the second is not native English (Miles).

If ArrayElement[T] then it should be ArrayElementReified[T] or
ArrayElementsReified[T] (plural) but IMO
it can be just ArrayReified[T] since it is not important to know that
it is really about the array elements and actually the half-
concretized array as whole is still abstract if the constituents i.e.
array elements are not yet reified.

[Dave]

Reflectable since manifest is integrated with reflection

> [T: TypeReflectable]
> [T: ClassReflectable]
> [T: ArrayReflectable]

On 20 mei, 18:21, martin odersky <martin.oder...@epfl.ch> wrote:

> Prof., EPFL <http://www.epfl.ch> and Chairman, Typesafe<http://www.typesafe.com>

[Dave]

Visible or Seen?

[T: TypeVisible]
[T: ClassVisible]
[T: ArrayVisible]

[T: TypeSeen]
[T: ClassSeen]
[T: ArraySeen]

> > Tel. Typesafe: +41 21 691 4967- Tekst uit oorspronkelijk bericht niet weergeven -

[Erik Osheim]

I prefer 2a.

Programming languages often invent/introduce new words (or novel uses
of existing words) so I would rather go with words like "Arrayable"
that are suggestive (T can be used in an array) even if made up.

-- Erik

[Rex Kerr]

Indeed.  And surely "Classable" is not worse than Klass and Clazz and Tpe and so on.

[Luke Vilnis]

I prefer 1 very much over 2a or 2b. I think I like TypeInfo, ClassInfo, and ArrayInfo the best, though.

I also don't think that adjective names are a good idea - it really isn't adjectival (has-a vs. is-a). I think in a language like Scala that has both subtyping and type classes, making the distinction is even more important. Maybe Haskell can get away with confusing the two because type classes are its primary form of ad-hoc polymorphism. Not being knowledgeable about this stuff, it's possible I may have stumbled onto a religious issue - maybe I missed the thread where this was already decided.

I will say that as a recent Scala noob I was confused by context bounds precisely because I thought they were adjectives when they were actually nouns - ":"'s and adjectival names actually mislead the new user as to how context bounds desugar. Any Scala user has to know what implicit arguments are, and pretending context bounds aren't arguments actually increases the surface area of the language instead of simplifying it. T is not Typeable - we are passing in a TypeTag. Pretending otherwise is just complicating the issue.

Also, if they absolutely must be adjectives, why not "TypeTagged", "ClassTagged", "ArrayTagged"?

[Jason Zaugg]

On Mon, May 21, 2012 at 2:04 AM, Luke Vilnis <lvi...@gmail.com> wrote:
> I also don't think that adjective names are a good idea - it really isn't
> adjectival (has-a vs. is-a). I think in a language like Scala that has both
> subtyping and type classes, making the distinction is even more
> important. Maybe Haskell can get away with confusing the two because type
> classes are its primary form of ad-hoc polymorphism. Not being knowledgeable
> about this stuff, it's possible I may have stumbled onto a religious issue -
> maybe I missed the thread where this was already decided.
>
> I will say that as a recent Scala noob I was confused by context bounds
> precisely because I thought they were adjectives when they were actually
> nouns - ":"'s and adjectival names actually mislead the new user as to how
> context bounds desugar. Any Scala user has to know what implicit arguments
> are, and pretending context bounds aren't arguments actually increases the
> surface area of the language instead of simplifying it. T is not Typeable -
> we are passing in a TypeTag. Pretending otherwise is just complicating the
> issue.

+1.

I also think the search for something that doubles as a noun and an
adjective is misguided.

-jason

[Kevin Wright]

In order of preference:

Reified[T]/Reified[Class[T]]/Reified[Array[T]]  -  Elegant and flexible, *minor* concern about use of past tense

Reified[T]/ReifiedClass[T]/ReifiedArray[T]  -  Will read nicely at both the point of use and in a context bound

TypeKnown/ClassKnown/ArrayKnown  -  Cleanly expresses the actual goal!

TypeTag/ClassTag/ArrayTag  -  Nicely abstract, may not be a bad idea to avoid expressing intent :)

TypeBound/ClassBound/ArrayBound  -  Implies usage as subcategories of context bounds (but TypeBound is overloaded)

WithClass/WithType/WithArrayBuilder  -  but I can see it looking odd in some contexts

Typeish/Classish/Arrayish  -  The Tolkein fan in me loves them!

TypeDesc/ClassDesc/ArrayDesc  -  No strong feelings either way

TypeTagged/ClassTagged/ArrayTagged  -  As above, but more verbose

TypeInfo/ClassInfo/ArrayInfo  -  TypeInfo overloaded in other contexts

TypeReifiable/ClassReifiable/ArrayReifiable  -  ArrayReifiable is unpleasant to speak out loud

Typeable/Classable/Arrayable  -  Arrayable feels wrong

Typeable/Classifyable/Arrayable  -  Just... no

Typely/Arrayly/Classly  -  :)

TypeReified/ClassReified/ArrayReified  -  It's cleaner with word ordering reversed

TypeVisabale/ClassVisible/ArrayVisible  -  Wrong to suggest that an array *has already* been seen

TypeSeen/ClassSeen/ArraySeen  -  Wrong to suggest that an array *has already* been seen

TypeReflectable/ClassReflectable/ArrayReflectable  -  Sends entirely the wrong message, these are far more widely useful

[Chris Marshall]

I agree with Jason about the noun/adjective point - and it's pretty clear that there is no adjective "scheme" which works for all of Class, Array and Type (hence a noun is probably a better bet). 

I also like this analysis from Kevin - I would go for any of the top 4 (I like Rex's *Known suggestion - it's much clearer at the point of use). All solutions are going to be slightly confusing , mirroring the general confusion between compile-time and run-time and what is actually going on.

Chris

---

Date: Mon, 21 May 2012 09:22:47 +0100
Subject: Re: [scala-internals] Poll on how to name manifest replacements
From: kev.lee...@gmail.com
To: scala-i...@googlegroups.com

[Peter Empen]

Just a vote from the user's point of view:

In any case, let's retain context bounds: [T : X] with X to be decided
on. Things like X[T] would be rather confusing.

As to X, I feel the 'Tag' suffix is vague. Instead, I'd prefer a
suffix capable expressing what this context bound is good for. Is it
used for reflecting or rather reifying T? For instance if you claim
it's purpose is closer to 'reflect' T, just go with Dave's last
suggestion:

[T: TypeReflectable] or even [T: Reflectable]
[T: ClassReflectable]
[T: ArrayReflectable]

If it's closer to 'reification' replace 'Reflectable' with
'Reifyable'.

[T: TypeReifyable] or even [T: Reifyable]
[T: ClassReifyable]
[T: ArrayReifyable]

A last alternative comming to my mind: If it's right to tell that 'the
compiler reifies T', as opposite to 'the user might reify T', we
should drop '...able':

[T: TypeReified] or even [T: Reified]
[T: ClassReified]
[T: ArrayReified]

Last, once the suffix is appropriate, it doesn't matter if its longer
than the 3 characters of 'Tag'.

Peter

[Ismael Juma]

On Mon, May 21, 2012 at 6:31 AM, Jason Zaugg <jza...@gmail.com> wrote:

+1.

I also think the search for something that doubles as a noun and an
adjective is misguided.

I also agree with this. I personally like the *Tag suggestion although I understand concerns around the overloaded meaning.

Best,

Ismael

[Dave]

> TypeKnown/ClassKnown/ArrayKnown  -  Cleanly expresses the actual goal!

> TypeVisabale/ClassVisible/ArrayVisible  -  Wrong to suggest that an array *has already* been seen
TypeSeen/ClassSeen/ArraySeen  -  Wrong to suggest that an array *has
already* been seen

Between Known and Seen there is a contradiction in what you say.
For Known it is the same as for Seen and Visible since one can not
know or see what is not reified (concretized) because it is even
unthinkable. With Known or Seen it is known or seen by the Scala
compiler.

[martin odersky]

On Mon, May 21, 2012 at 12:00 PM, Peter Empen <peter...@arcor.de> wrote:

Just a vote from the user's point of view:

In any case, let's retain context bounds: [T : X] with X to be decided
on. Things like X[T] would be rather confusing.

As to X, I feel the 'Tag' suffix is vague. Instead, I'd prefer a
suffix capable expressing what this context bound is good for. Is it
used for reflecting or rather reifying T? For instance if you claim
it's purpose is closer to 'reflect' T, just go with Dave's last
suggestion:

[T: TypeReflectable] or even [T: Reflectable]
[T: ClassReflectable]
[T: ArrayReflectable]

If it's closer to 'reification' replace 'Reflectable' with
'Reifyable'.

[T: TypeReifyable] or even [T: Reifyable]
[T: ClassReifyable]
[T: ArrayReifyable]

My issue with that is that Reifiable is tech jargon. Most programmers would not know what it meant and feel that things go over their head.

E.g. [T: Arrayable]  means "someone can make an array out of T elements", no need to mention Reification, or Reflection.

Cheers

 - Martin

[Kevin Wright]

Not so!

You can Know that it's possible to create an Array[Int] without actually having Seen an instance of one.

[Dave]

But it is
TypeSeen
ClassSeen
ArraySeen

It is not InstanceSeen

The Type, Class and Array have been checked by the compiler and thus
have been seen (and also known).

On 21 mei, 12:21, Kevin Wright <kev.lee.wri...@gmail.com> wrote:

[Dave]

Sorry, used the wrong word. I shouldn't use 'checked' because the
whole reason is that the type is unchecked by type erasure by the
compiler:
Corrected:
"The Type, Class and Array have been 'written into a tag' by the

compiler and thus
have been seen (and also known)."

Maybe it should be specified what moment (compile-time/runtime) and
perspective ( library programmer, application programmer, compiler,
jvm) the naming refers to then it is easier to decide whther it should
be a participle or an -able adjective and who knows or sees what.

> > having Seen an instance of one.- Tekst uit oorspronkelijk bericht niet weergeven -

[Josh Suereth]

+1

Knowing reify implies you've lived in java land for a bit.   When my publisher asked about the word I did a survey of friends.   Reify is a great word, but not as well known as you might guess.

[Kevin Wright]

For the majority of people first seeing this, I suspect they'd start with the intuitive understanding that:

ArraySeen[T] = an Array of T has been seen

It's the wrong interpretation, but it *will* happen. So I'd like a convention that minimises that risk as much as is possible.  Now imagine having to give these people the correct explanation:

"The compiler has seen that Arrays of Type T can be created".

Which seems clumsier than it needs to be, in large part because you have to couch "seen" in the present perfect tense

Now compare for ArrayKnown[T]:

"The compiler Knows an Array[T] can be created"

Present Simple.  It expresses the same idea, but far more cleanly, and far more readily comprehended for non-native-English speakers.

Of course.. We still have reification to explain, and the types/values and compile-time/run-time dichotomies.  But that's the essential complexity of the problem, which is unavoidable;  the best that we can hope to achieve is eliminating as much accidental complexity and potential confusion as we are able.

[Josh Suereth]

With that argument I think "ArrayBuilder[T]" would be good enough.   scala.reflect.api.Type[T] and scala.reflect.api.Class[T] could be the other two.

If we're treating these as nouns, and we *know* they're passed in as arguments, why not name them what they are?  Yes, I know a TypeTag is not quite a Type right now, but we could still make this work.

Also, error messages would be a lot better when constructing arrays.  "Could not find implicit value for ArrayBuilder[T]" makes a lot make sense than ClassManifest[T], as it stands.

- Josh

[Nils Kilden-Pedersen]

[T: TypeCapture]

etc...

On Sun, May 20, 2012 at 5:21 PM, martin odersky <martin....@epfl.ch> wrote:

Scala 2.10 will introduce a new set of types that will eventually replace manifests. The new-style manifests fulfill similar roles to what Manifest/ClassManifest/OptManifest do now, yet are cleanly integrated with reflection. It was not possible to do that with the old style of manifests, and neither was it possible to migrate manifests safely to the new style. That's why for 2.10, old-style manifests will exists together with the new types, but will be deprecated   The compiler will in any case happily infer either type for you, depending on what you specified. 

There's still a question on what the new types should be named. Just to set the context, we picked "Manifest" as a name before because it can be used as an adjective. So the typical usage as a context bound, as in

  [T: Manifest]

reads will, because it suggests that "Manifest" is a property of the type "T". "ClassManifest" works slightly less well, though. But anyway, these names are no longer available, and we need new ones.

I wanted to get your opinion on what naming scheme you prefer. There are essentially three variants. In current trunk, we use the following names: 

Alternative 1:

[T: TypeTag]   Instances of type T come with a descriptor that describes their whole type.  This is analogous to Manifest in 2.8/2.9.

[T: ClassTag]   Instances of type T come with a descriptor that describes their erasure in a top-level Java class. This is analogous to ClassManifest in 2.8/2.9.

[T: ArrayTag]   It is possible to form arrays with instances of type T as elements. This is the same as ClassManifest in 2.8/2.9; it has been split off in 2.10 because some platforms (e.g. GWT) do not know Java classes, yet can still form arrays.

All of that is more or less fine, except that none of the names above are adjectives. So the context bounds do not read very well. I also don't like the slightly different signification of ArrayTag from the others. TypeTag, ClassTag tell you about descriptors that come with the type, whereas ArrayTag means that you can form an array from elements of the type. Prompted by Simon PJ's Scala Days talk, where he showed "Typeable" as a name for something in Haskell that's similar to a manifest, I started to think of an alternative:

Alternative 2a:

[T: Typeable]    Instances of type T come with a descriptor that describes their whole type. 

[T: Classable]  Instances of type T come with a descriptor that describes their erasure in a top-level Java class.

[T: Arrayable]   Instances of type T can be aligned in an array.

I personally like that naming scheme because they are all words in the english dictionary and have the right connotations. But "classable" and "arrayable" are pretty uncommon english words and native speakers such as Miles found their use "ghastly" ;-). I believe in particular "classable" is contentious as a term. So to be slightly less contentions we could also do 

Alternative 2b:

[T: Typeable]    

[T: Classifiable]  

[T: Arrayable] 

"Classifiable" is a slightly longer word than "classable" and to my eyes not as directly connected with the meaning of runtime class. But but it's more familiar.

So, what do you think? I am trying to get some feedback on this, in particular from native english speakers (but not only from them). You can simply respond with 1/2a/2b depending on which option you like best, or you can argue for one of the options, or maybe even propose yet another naming scheme (although we went through this already and I really would like to keep the current discussion focussed).

Cheers

 - Martin

 

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe

[Dave]

> > My issue with that is that Reifiable is tech jargon. Most programmers
>
> would not know what it meant and feel that things go over their head.
>
> E.g. [T: Arrayable]  means "someone can make an array out of T elements",
> no need to mention Reification, or Reflection.
>

But if you make an array out of type erased elements then it is
Arrayable too so Arrayable doesn't tell about its intention.

[Peter Empen]

@Martin

> >> My issue with that is that Reifiable is tech jargon. Most programmers
> > would not know what it meant and feel that things go over their head.
>
> > E.g. [T: Arrayable]  means "someone can make an array out of T elements",
> > no need to mention Reification, or Reflection.

@Josh

> Knowing reify implies you've lived in java land for a bit. When my
> publisher asked about the word I did a survey of friends. Reify is a
> great word, but not as well known as you might guess.

Indeed, 'Reifiable' *is* tech jargon. But look out:

Java beginners and simple-minded Java programmers don't necessarily
know about reflection. Clearly that could not be a reason for Java/
Scala libraries to abandon the term 'reflection'.

Now, even more experienced Java guys have occasionally some difficulty
to explain the mechanics/effects of erasure. So, should the term
"reification' really be replaced in the Scala library and if so which
term is suitable? If anybody uses this feature shouldn't she also
understand the concept behind it - as Viktor put it? If so why to
replace at all?

I personally don't have a replacement I feel totally comfortable with.
'Manifest' was a good invention but afaik they don't use this term as
a synonym for reification elsewhere. How do they cal it in C#, for
instance?

Btw, 'Arrayable' is ok for me even if it sounds strange. I understand
it is meant by you as a short for
[T: ArrayCreatable]

Some more ideas for TypeTag/ClassTag:
[T: Reified]
[T: Reflectable]
[T: MetaTyped]
[T: Explicitly]
[T: Saved]
[T: Available]
[T: Inspectable]
[T: NonErased]
[T: FirstClass]

Peter

[Kevin Wright]

Agreed.  And I must admit that I'm leaning ever more towards some variant on a theme of "ArrayBuilder".

With that in mind then, how does everyone feel about this proposal?

• HasType
• HasClass
• HasArrayBuilder

It should look very intuitive used in context bounds and implicit arguments, and it appears to be asking a question; nicely falling in line with the convention established by CanBuildFrom

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Dave]

> [T: NonErased]

Indeed

[T: TypeUnerased]
[T: ClassUnerased]
[T: ArrayUnerased]

[Dave]

or with -able
[T: TypeUnerasable]
[T: ClassUnerasable]
[T: ArrayUnerasable]

[Josh Suereth]

Reify isn't a concept you need a word for in this instance IMHO.

Since reifying is making an abstract concept a real thing, isn't that what you're doing I'd you take in a Class or a Type?  I get a first-class object I can use that represents the abstract type.   We reify things all the time in c.s.

It's only with generics and java VM vs. .net where the word reify holds a particular significance that is *less* than the meaning of the word.

The object passed is a reified type not the verb of reifying the type.   The compiler does the reification.   All I need to know is at run time I have an instance of a Type, which is not a normal run time thing.

So if you want reify in the name:

ReifiedType, ReifiedClass and that falls over for array.

I'm still pushing for:

ArrayBuilder[T]
Class[T]
Type[T]

Why add extraneous implementation details?

It's not ClosedFunction1 it's just Function1.  The closure is computed by the compiler and I deal with a value of a function that happened to be generated using some closure computation.  Also not every Function is actually a closure...

Same argument for reify.  Note: you potentially could construct values of Type by hand, where reification doesn't play any role.

[Eugene Burmako]

Class[T] sounds nice. I mean, the real java.lang.Class.

However there is a problem with Type. First, our Type is not polymorphic, and second, reified types are essentially type factories, not types. But I like the idea a lot.

On May 21, 2012 2:51 PM, "Josh Suereth" <joshua....@gmail.com> wrote:

Reify isn't a concept you need a word for in this instance IMHO.

Since reifying is making an abstract concept a real thing, isn't that what you're doing I'd you take in a Class or a Type?  I get a first-class object I can use that represents the abstract type.   We reify things all the time in c.s.

It's only with generics and java VM vs. .net where the word reify holds a particular significance that is *less* than the meaning of the word.

The object passed is a reified type not the verb of reifying the type.   The compiler does the reification.   All I need to know is at run time I have an instance of a Type, which is not a normal run time thing.

So if you want reify in the name:

ReifiedType, ReifiedClass and that falls over for array.

I'm still pushing for:

ArrayBuilder[T]
Class[T]
Type[T]

Why add extraneous implementation details?

It's not ClosedFunction1 it's just Function1.  The closure is computed by the compiler and I deal with a value of a function that happened to be generated using some closure computation.  Also not every Function is actually a closure...

Same argument for reify.  Note: you potentially could construct values of Type by hand, where reification doesn't play any role.

On May 21, 2012 8:31 AM, "Peter Empen" <peter...@arcor.de> wrote:
>
> @Martin

> > >> My issue w...

[Kevin Wright]

I assume these would be Class and Type in a different package :)

In which case the question becomes:

Is the improved clarity of this convention outweighed by the cognitive burden of the shadowed names?

It's a tough question, and almost entirely subjective.  I can't even decide what my own opinion is here!

[Josh Suereth]

We have precedence in scala.collection.Seq vs. scala.collection.mutable.Seq

SO, java.reflect.Class would be different from scala.reflect.Class.   I think that's 'OK'.

It's Type that has me concerned, as Eugene mentioned.

[Chris Marshall]

But Class is in java.lang, not java.reflect. This will cause issues because java.lang._ is implicitly imported in every scala file

Chris

---

From: joshua....@gmail.com
Date: Mon, 21 May 2012 09:10:58 -0400
Subject: Re: [scala-internals] Re: Poll on how to name manifest replacements
To: scala-i...@googlegroups.com

[Eugene Burmako]

We can generate java.lang.Class[T] directly instead of wrapping it. That is what I especially like about this idea!

[Matthew Pocock]

On 21 May 2012 01:04, Luke Vilnis <lvi...@gmail.com> wrote:

Also, if they absolutely must be adjectives, why not "TypeTagged", "ClassTagged", "ArrayTagged"?

That's the least bad suggestion I've seen so far.

Matthew

--

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

[Josh Suereth]

Good call!   That makes a  heck of a lot of sense too, given what ClassManifest did.   For Arrays, can you implicitly take a java.lang.Class[T] into an ArrayBuilder[T] or ArrayTag[T] or whatever we call it?

- Josh

[Eugene Burmako]

Sure why not

[Kevin Wright]

Ho ho! Now it's starting to get interesting :)

In which case my support is now wholeheartedly behind the Class[T]/Type[T]/ArrayBuilder[T] proposal :)

[Roland Kuhn]

I don’t know about implementation issues, but from a usage perspective I like this a lot!

[√iktor Ҡlang]

And typeOf vs classOf ;-)

[Eugene Burmako]

Yeah, exactly. I was planning to add typeOf as an incantation once I get home from EPFL :)

[Eugene Burmako]

Allrighty, I just talked to Martin, and he seems pretty okay about the Class idea. The only minor question left is whether we are fine with having implicit values of type java.lang.Class flying around. 

Type is tough. To put this in perspective, here is how tags work now. Each tag carries its mirror and a type creator. You can call 'tpe' to get a type built by the creator, or you can call 'in' to instantiate a tag in a different mirror. I am not sure how exactly to integrate this functionality with the existing Type class. Can we have a different name?

Upd. I vaguely recall seeing a TypeProxy somewhere. Maybe we can replace tags with proxies that mimic themselves as normal types + also know how to recreate themselves in a different mirror? Paul, Martin, what do you think?

Speaking of ArrayBuilder, Martin said that we definitely need a different name, because we already have an unrelated ArrayBuilder in stdlib.

On 21 May 2012, at 18:09, "√iktor Ҡlang" <viktor...@gmail.com> wrote:

[Stefan Zeiger]

On 2012-05-21 18:18, Eugene Burmako wrote:
> Speaking of ArrayBuilder, Martin said that we definitely need a
> different name, because we already have an unrelated ArrayBuilder in
> stdlib.

ArrayFactory (he said, wandering off into Java design patterns land)?

(Personally, I'd just stick with TypeTag/ClassTag/ArrayTag, unless we
can call them Curly, Larry and Moe)

-sz

[Grzegorz Kossakowski]

On 21 May 2012 18:18, Eugene Burmako <eugene....@epfl.ch> wrote:

Speaking of ArrayBuilder, Martin said that we definitely need a different name, because we already have an unrelated ArrayBuilder in stdlib.

ArrayFactory?

--
Grzegorz Kossakowski

[Kevin Wright]

ArrayMaker, it sounds at least 10x morse awesome than ArrayFactory

[√iktor Ҡlang]

Why do we need an ArrayX? Java has java.lang.reflect.Array, which is used to dynamically create arrays, so we could simply have a scala.reflect.Array, which takes an implicit class for the component type?

Cheers,

√

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Eugene Burmako]

Decoupling array creation from the java reflection seems to be a good idea.

For example, Greg's ScalaGWT stuff doesn't know anything about classes and erasures, but it still wants to create arrays. 

[√iktor Ҡlang]

On Mon, May 21, 2012 at 8:36 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

Decoupling array creation from the java reflection seems to be a good idea.

For example, Greg's ScalaGWT stuff doesn't know anything about classes and erasures, but it still wants to create arrays. 

I suspect in his case he'll be just fine with Object[]?

 

On 21 May 2012 19:18, √iktor Ҡlang <viktor...@gmail.com> wrote:

Why do we need an ArrayX? Java has java.lang.reflect.Array, which is used to dynamically create arrays, so we could simply have a scala.reflect.Array, which takes an implicit class for the component type?

Cheers,

√

On Mon, May 21, 2012 at 7:09 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

ArrayMaker, it sounds at least 10x morse awesome than ArrayFactory

On 21 May 2012 17:22, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:

On 21 May 2012 18:18, Eugene Burmako <eugene....@epfl.ch> wrote:

Speaking of ArrayBuilder, Martin said that we definitely need a different name, because we already have an unrelated ArrayBuilder in stdlib.

ArrayFactory?

--
Grzegorz Kossakowski

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Jan Vanek]

On 21.05.2012 21:14, √iktor Ҡlang wrote:

On Mon, May 21, 2012 at 8:36 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

Decoupling array creation from the java reflection seems to be a good idea.

For example, Greg's ScalaGWT stuff doesn't know anything about classes and erasures, but it still wants to create arrays. 

I suspect in his case he'll be just fine with Object[]?

Perhaps one wants to have pieces of code shared? That would be the explanation why ArrayX is needed. Well, if this is not the case (need for shared code), does the compiler require the witness for array creation in ScalaGWT? (would be nice if this were not necessary).

Regards,
Jan

[Eugene Burmako]

Let's summon Greg for more details

[√iktor Ҡlang]

On Mon, May 21, 2012 at 9:30 PM, Jan Vanek <j3v...@googlemail.com> wrote:

On 21.05.2012 21:14, √iktor Ҡlang wrote:

On Mon, May 21, 2012 at 8:36 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

Decoupling array creation from the java reflection seems to be a good idea.

For example, Greg's ScalaGWT stuff doesn't know anything about classes and erasures, but it still wants to create arrays. 

I suspect in his case he'll be just fine with Object[]?

Perhaps one wants to have pieces of code shared? That would be the explanation why ArrayX is needed. Well, if this is not the case (need for shared code), does the compiler require the witness for array creation in ScalaGWT? (would be nice if this were not necessary).

* casts Summon on Greg *

[Sébastien Doeraene]

On Mon, May 21, 2012 at 9:14 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Mon, May 21, 2012 at 8:36 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

Decoupling array creation from the java reflection seems to be a good idea.

For example, Greg's ScalaGWT stuff doesn't know anything about classes and erasures, but it still wants to create arrays. 

I suspect in his case he'll be just fine with Object[]?

No, I don't think he can. At least, I wouldn't with Ozma, aka Scala-Mozart. In Int[] you can put directly Int's. In Object[] you need to box Int's in Integer's and unbox them later... for strictly nothing. Besides, this requires to hack the 'erasure' phase, which I don't wanna do ^^

Cheers,
Sébastien

[Josh Suereth]

I believe you're trivializing it. 

Everywhere in Scala the compiler requires a ClassManifest to make arrays.  Rather than *fight* the compiler, it'd be nice to have a smaller surface area to replace Array creation, specifically the part that creates "ArrayTag".   That way, you have to touch less code to make Scala compiler to Javascript.

It's not about "being ok with Object[]", but having code that using implicit ClassManfiest/Manifest just to generate arrays not get in the way of generating JavaScript.

- Josh

[√iktor Ҡlang]

On Mon, May 21, 2012 at 9:35 PM, Josh Suereth <joshua....@gmail.com> wrote:

I believe you're trivializing it. 

Everywhere in Scala the compiler requires a ClassManifest to make arrays.  Rather than *fight* the compiler, it'd be nice to have a smaller surface area to replace Array creation, specifically the part that creates "ArrayTag".   That way, you have to touch less code to make Scala compiler to Javascript.

It's not about "being ok with Object[]", but having code that using implicit ClassManfiest/Manifest just to generate arrays not get in the way of generating JavaScript.

I think you misunderstood me. My point is that if you want to be Class-agnostic, you can't really work with arrays, since on the JVM they're very tightly knit to classes.

So, back to my point: java.lang.reflect.Array + implicit Class[T] would do the trick when it comes to creating arrays, and you wouldn't need a 3rd party jar. So all that is needed is to strap on a Scala API on top of that.

[martin odersky]

On Mon, May 21, 2012 at 9:41 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Mon, May 21, 2012 at 9:35 PM, Josh Suereth <joshua....@gmail.com> wrote:

I believe you're trivializing it. 

Everywhere in Scala the compiler requires a ClassManifest to make arrays.  Rather than *fight* the compiler, it'd be nice to have a smaller surface area to replace Array creation, specifically the part that creates "ArrayTag".   That way, you have to touch less code to make Scala compiler to Javascript.

It's not about "being ok with Object[]", but having code that using implicit ClassManfiest/Manifest just to generate arrays not get in the way of generating JavaScript.

I think you misunderstood me. My point is that if you want to be Class-agnostic, you can't really work with arrays, since on the JVM they're very tightly knit to classes.

But I believe for Javascript generation via GWT it's different. Greg should be able to give details.

Cheers

 - Martin

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[√iktor Ҡlang]

On Mon, May 21, 2012 at 9:44 PM, martin odersky <martin....@epfl.ch> wrote:

On Mon, May 21, 2012 at 9:41 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Mon, May 21, 2012 at 9:35 PM, Josh Suereth <joshua....@gmail.com> wrote:

I believe you're trivializing it. 

Everywhere in Scala the compiler requires a ClassManifest to make arrays.  Rather than *fight* the compiler, it'd be nice to have a smaller surface area to replace Array creation, specifically the part that creates "ArrayTag".   That way, you have to touch less code to make Scala compiler to Javascript.

It's not about "being ok with Object[]", but having code that using implicit ClassManfiest/Manifest just to generate arrays not get in the way of generating JavaScript.

I think you misunderstood me. My point is that if you want to be Class-agnostic, you can't really work with arrays, since on the JVM they're very tightly knit to classes.

But I believe for Javascript generation via GWT it's different. Greg should be able to give details.

What's your take on the following:

scala.reflect.Type[T]

java.lang.Class[T]

so:

def foo[T : Type]

def foo[C : Class]

Then Array.apply() can simply use a Class-witness and use java.lang.reflect.Array?

So no need for ArrayBuilder/ArrayInfo/ArrayMaker/Arrayer/whathaveyou

So things fall into two categories instead of three?

Or I am just completely missing some key piece here and everyone's just flabbergasted at my insanity?

Cheers,

√

[Daniel Sobral]

Doesn't this tie arrays in Scala to the JVM?

--
Daniel C. Sobral

I travel to the future all the time.

[Jan Vanek]

On 21.05.2012 21:55, √iktor Ҡlang wrote:

What's your take on the following:

scala.reflect.Type[T]

java.lang.Class[T]

so:

def foo[T : Type]

def foo[C : Class]

Then Array.apply() can simply use a Class-witness and use java.lang.reflect.Array?

So no need for ArrayBuilder/ArrayInfo/ArrayMaker/Arrayer/whathaveyou

So things fall into two categories instead of three?

Or I am just completely missing some key piece here and everyone's just flabbergasted at my insanity?

:-)
I had the same thoughts about getting rid of ArrayX as you. So, as I understand it, having [C: Class] allows to create arrays, sure, but sometimes one wants to create arrays with "less support" than Class.

Aahhh, or I am insane, you want some "Class" simulation-magic for JS too??? Could be possible, the only negative is that you close the door for performance optimization, because (if I understand it), ArrayX would allow to create arrays via code like new int[len] or new MyClass[len] whereas the [C: Class] would always force the way via reflect.Array.

[√iktor Ҡlang]

Why would it? Just add a type alias for Class in scala.reflect that happens to point to java.lang.Class for the JVM, then the impl of Array.apply can be just as language agnostic.

Or am I missing vital info here?

[Miles Sabin]

On Mon, May 21, 2012 at 8:55 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:
> What's your take on the following:
>
> scala.reflect.Type[T]
> java.lang.Class[T]
>
> so:
>
> def foo[T : Type]
> def foo[C : Class]
>
> Then Array.apply() can simply use a Class-witness and use
> java.lang.reflect.Array?
>
> So no need for ArrayBuilder/ArrayInfo/ArrayMaker/Arrayer/whathaveyou
>
> So things fall into two categories instead of three?
>
> Or I am just completely missing some key piece here and everyone's just
> flabbergasted at my insanity?

+1

If you are then so am I. This is the best suggestion I've seen so far :-)

Cheers,


Miles

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

[Miles Sabin]

On Mon, May 21, 2012 at 9:21 PM, Miles Sabin <mi...@milessabin.com> wrote:
>> scala.reflect.Type[T]
>> java.lang.Class[T]
>>
>> so:
>>
>> def foo[T : Type]
>> def foo[C : Class]
>>
>> Then Array.apply() can simply use a Class-witness and use
>> java.lang.reflect.Array?
>>
>> So no need for ArrayBuilder/ArrayInfo/ArrayMaker/Arrayer/whathaveyou
>>
>> So things fall into two categories instead of three?
>>
>> Or I am just completely missing some key piece here and everyone's just
>> flabbergasted at my insanity?
>
> +1
>
> If you are then so am I. This is the best suggestion I've seen so far :-)

Obvious, but worth flagging up anyway: if you want both reified type
info *and* the means of constructing values then you just ask for
both,

def foo[T : Type : Class] ...

[√iktor Ҡlang]

On Mon, May 21, 2012 at 10:25 PM, Miles Sabin <mi...@milessabin.com> wrote:

On Mon, May 21, 2012 at 9:21 PM, Miles Sabin <mi...@milessabin.com> wrote:
>> scala.reflect.Type[T]
>> java.lang.Class[T]
>>
>> so:
>>
>> def foo[T : Type]
>> def foo[C : Class]
>>
>> Then Array.apply() can simply use a Class-witness and use
>> java.lang.reflect.Array?
>>
>> So no need for ArrayBuilder/ArrayInfo/ArrayMaker/Arrayer/whathaveyou
>>
>> So things fall into two categories instead of three?
>>
>> Or I am just completely missing some key piece here and everyone's just
>> flabbergasted at my insanity?
>
> +1
>
> If you are then so am I. This is the best suggestion I've seen so far :-)

Obvious, but worth flagging up anyway: if you want both reified type
info *and* the means of constructing values then you just ask for
both,

 def foo[T : Type : Class] ...

That's sexy and you know it

 

Cheers,


Miles

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

[Grzegorz Kossakowski]

On 21 May 2012 21:55, √iktor Ҡlang <viktor...@gmail.com> wrote:

What's your take on the following:

scala.reflect.Type[T]

java.lang.Class[T]

so:

def foo[T : Type]

def foo[C : Class]

Then Array.apply() can simply use a Class-witness and use java.lang.reflect.Array?

So no need for ArrayBuilder/ArrayInfo/ArrayMaker/Arrayer/whathaveyou

So things fall into two categories instead of three?

Or I am just completely missing some key piece here and everyone's just flabbergasted at my insanity?

What an epic thread!

Before I dive into problem with GWT (and with any Scala2JS compiler) related to Arrays let me ask a question about above proposal. What about:

def foo[T : Class](x: T): Array[T] = Array(2)(x) //array with x as initial value everywhere

def bar[C: Class](x: C): Array[Array[C]] = {

  val a = Array(1)(x)

  foo(a) //what should be passed as an implicit arg? here T = Array[C] and we have only Class[C] and not Class[Array[C]]

}

See also: https://groups.google.com/d/msg/scala-internals/WTb8cz1oQ4E/4rAT0Rh7Tj0J

--
Grzegorz Kossakowski

[√iktor Ҡlang]

On Mon, May 21, 2012 at 10:48 PM, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:

On 21 May 2012 21:55, √iktor Ҡlang <viktor...@gmail.com> wrote:

What's your take on the following:

scala.reflect.Type[T]

java.lang.Class[T]

so:

def foo[T : Type]

def foo[C : Class]

Then Array.apply() can simply use a Class-witness and use java.lang.reflect.Array?

So no need for ArrayBuilder/ArrayInfo/ArrayMaker/Arrayer/whathaveyou

So things fall into two categories instead of three?

Or I am just completely missing some key piece here and everyone's just flabbergasted at my insanity?

What an epic thread!

Before I dive into problem with GWT (and with any Scala2JS compiler) related to Arrays let me ask a question about above proposal. What about:

def foo[T : Class](x: T): Array[T] = Array(2)(x) //array with x as initial value everywhere

def bar[C: Class](x: C): Array[Array[C]] = {

  val a = Array(1)(x)

  foo(a) //what should be passed as an implicit arg? here T = Array[C] and we have only Class[C] and not Class[Array[C]]

}

Don't you need to use ofDim there?

 

See also: https://groups.google.com/d/msg/scala-internals/WTb8cz1oQ4E/4rAT0Rh7Tj0J

--
Grzegorz Kossakowski

[Miles Sabin]

On Mon, May 21, 2012 at 9:48 PM, Grzegorz Kossakowski
<grzegorz.k...@gmail.com> wrote:
> Before I dive into problem with GWT (and with any Scala2JS compiler) related
> to Arrays let me ask a question about above proposal. What about:
>
> def foo[T : Class](x: T): Array[T] = Array(2)(x) //array with x as initial
> value everywhere
>
> def bar[C: Class](x: C): Array[Array[C]] = {
>   val a = Array(1)(x)
>   foo(a) //what should be passed as an implicit arg? here T = Array[C] and
> we have only Class[C] and not Class[Array[C]]
> }

In Java you'd only need Class<C> to create C[], C[][], etc. (just use
java.lang.reflect.Array.newInstance with the appropriate number of
dimensions), so why would we need anything more here?

[√iktor Ҡlang]

On Mon, May 21, 2012 at 11:09 PM, Miles Sabin <mi...@milessabin.com> wrote:

On Mon, May 21, 2012 at 9:48 PM, Grzegorz Kossakowski
<grzegorz.k...@gmail.com> wrote:
> Before I dive into problem with GWT (and with any Scala2JS compiler) related
> to Arrays let me ask a question about above proposal. What about:
>
> def foo[T : Class](x: T): Array[T] = Array(2)(x) //array with x as initial
> value everywhere
>
> def bar[C: Class](x: C): Array[Array[C]] = {
>   val a = Array(1)(x)
>   foo(a) //what should be passed as an implicit arg? here T = Array[C] and
> we have only Class[C] and not Class[Array[C]]
> }

In Java you'd only need Class<C> to create C[], C[][], etc. (just use
java.lang.reflect.Array.newInstance with the appropriate number of
dimensions), so why would we need anything more here?

These are the droids you're looking for: http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Array.html#newInstance(java.lang.Class, int...)

 

Cheers,


Miles

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

[Grzegorz Kossakowski]

On 21 May 2012 23:09, Miles Sabin <mi...@milessabin.com> wrote:

In Java you'd only need Class<C> to create C[], C[][], etc. (just use
java.lang.reflect.Array.newInstance with the appropriate number of
dimensions), so why would we need anything more here?

That doesn't answer my question what implicit value should be passed when foo is called, right?

--
Grzegorz Kossakowski

[Grzegorz Kossakowski]

On 21 May 2012 23:13, √iktor Ҡlang <viktor...@gmail.com> wrote:

In Java you'd only need Class<C> to create C[], C[][], etc. (just use
java.lang.reflect.Array.newInstance with the appropriate number of
dimensions), so why would we need anything more here?

These are the droids you're looking for: http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Array.html#newInstance(java.lang.Class, int...)

Those dims has to be transmitted somehow from the call site into a method. I don't see how proposal to just go with plain Class allows that.

--
Grzegorz Kossakowski

[Miles Sabin]

Hmm ... good point.

Can we live with the overheads of this,

implicit def wrap[T : Class] : Class[Array[T]] =
java.lang.reflect.Array.newInstance(implicitly[Class[T]], 0).
getClass.asInstanceOf[Class[Array[T]]]

which given,

implicit def fakeImplicitClass[T : ClassManifest] =
classManifest[T].erasure.asInstanceOf[Class[T]]

Allows,

scala> implicitly[Class[String]]
res0: Class[String] = class java.lang.String

scala> implicitly[Class[Array[String]]]
res1: Class[Array[String]] = class [Ljava.lang.String;

scala> implicitly[Class[Array[Array[String]]]]
res2: Class[Array[Array[String]]] = class [[Ljava.lang.String;

[Jan Vanek]

Array.newInstance(classOf[C],0).getClass()

Ugly, sure. But assume you have ev: ArrayFactory and you need to pass "1-higher" array factory - you'd need to call/pass something like ev.arrayOf (or ev.nextArrayFactory, or some good name :-) - but still new instance - so not a big improvement over the Class-only model.

That said, I see the power shifting to the 3-parties variant.

--
Grzegorz Kossakowski

[Eugene Burmako]

@Miles. An implicit macro can take care of multi-dimensional class creation, so no implicits (except that macro) will be required.

@Greg. If it's fine for you to express `new Array[Array[T]]` as `implicitly[Class[Array[T]].newArray`, then let's follow this route. To be honest, in this case I find the minimalism more appealing than flexibility.

[Miles Sabin]

On Mon, May 21, 2012 at 10:43 PM, Eugene Burmako <eugene....@epfl.ch> wrote:
> @Miles. An implicit macro can take care of multi-dimensional class creation,
> so no implicits (except that macro) will be required.

Yes, it occurred to me that an implicit macro would help here. But
there's still the (hotspot eliminated?) overhead of creating 0-length
arrays simply so that we can synthesize their corresponding Class
objects.

> @Greg. If it's fine for you to express `new Array[Array[T]]` as
> `implicitly[Class[Array[T]].newArray`, then let's follow this route. To be
> honest, in this case I find the minimalism more appealing than flexibility.

[Eugene Burmako]

There is indeed that overhead, but I don't see a big problem here, since this is exactly how pre-2.10 behaves.  

If this proves to be annoying, we can precompute array types for, say, primitives, or the one who's annoyed can write his/her own macro.

[Miles Sabin]

On Mon, May 21, 2012 at 10:46 PM, Miles Sabin <mi...@milessabin.com> wrote:
> On Mon, May 21, 2012 at 10:43 PM, Eugene Burmako <eugene....@epfl.ch> wrote:
>> @Miles. An implicit macro can take care of multi-dimensional class creation,
>> so no implicits (except that macro) will be required.
>
> Yes, it occurred to me that an implicit macro would help here. But
> there's still the (hotspot eliminated?) overhead of creating 0-length
> arrays simply so that we can synthesize their corresponding Class
> objects.

But it does seem to work. Here's Greg's example on the REPL,

def foo[T : Class](x: T): Array[T] = {
val a = java.lang.reflect.Array.newInstance(implicitly[Class[T]], 1).
asInstanceOf[Array[T]]
a(0) = x
a

}

def bar[C: Class](x: C): Array[Array[C]] = {

val a = java.lang.reflect.Array.newInstance(implicitly[Class[C]], 1).
asInstanceOf[Array[C]]
a(0) = x
foo(a)
}

scala> bar("foo")
res0: Array[Array[String]] = Array(Array(foo))

[Grzegorz Kossakowski]

On 21 May 2012 23:33, Miles Sabin <mi...@milessabin.com> wrote:

On Mon, May 21, 2012 at 10:13 PM, Grzegorz Kossakowski
<grzegorz.k...@gmail.com> wrote:
> On 21 May 2012 23:09, Miles Sabin <mi...@milessabin.com> wrote:
>>
>>
>> In Java you'd only need Class<C> to create C[], C[][], etc. (just use
>> java.lang.reflect.Array.newInstance with the appropriate number of
>> dimensions), so why would we need anything more here?
>
>
> That doesn't answer my question what implicit value should be passed when
> foo is called, right?

Hmm ... good point.

Can we live with the overheads of this,

 implicit def wrap[T : Class] : Class[Array[T]] =
   java.lang.reflect.Array.newInstance(implicitly[Class[T]], 0).
     getClass.asInstanceOf[Class[Array[T]]]

which given,

 implicit def fakeImplicitClass[T : ClassManifest] =
   classManifest[T].erasure.asInstanceOf[Class[T]]

Yes, we can, see arrayClass and arrayManifest in current ClassManifest.

However, this approach assumes there's a way to implement wrap on other platforms. Let me show why this assumption is problematic by explaining in detail what's the problem with GWT.

Let's say we want to compile Scala code to JS with satisfying the following requirements:

• we preserve runtime semantics for both correct and incorrect code (meaning we'll throw something like ClassCastException both when Scala is run on JVM and in JS)
• we want allow casting as in regular Scala code with the same semantics (that's part of first bullet but wanted to highlight it)
• we want reasonably efficient arrays implementation in JS that emulate JVM arrays
• we are making the whole program compiler (meaning: there's no support for separate compilation)

Now you realize that your implementation of JVM arrays will need to emulate variance as in JVM and will need to emulate throwing ArrayStoreException. In order to do that you need to perform runtime subtyping checks on erased types (the ones JVM sees). We want to make arrays reasonably efficient so subtyping checks must be really, really fast, probably O(1) operation.

GWT team struggled with this issue for a while and they came up with a solution that exploits the fact that GWT is the whole program compiler so it statically knows all the erased types (including all types of arrays). Once they got the full list of erased types they just statically calculated boolean matrix indexed by types that expressed subtyping relationship among all types. This matrix is shipped to JavaScript in a very efficient form, loaded once and used everywhere when subtyping checks are needed at runtime in JavaScript code.

Obviously, for this to work you do not allow most of the reflection. Things like Class.forName is not supported but Class.getName (and Class itself) is supported because it does not allow creating new classes at runtime.

I struggled with this problem for a while when working on Scala+GWT and I came up with a little hack. I subclass ClassManifest with something called FactoryClassManifest. It's basically ClassManifest that does not refer to reflection but uses special factory for array creation: https://github.com/scalagwt/scalagwt-scala/blob/scalagwt/src/library/scala/reflect/FactoryClassManifest.scala#L69

As second step, I wrote a compiler phase that rewrites calls to regular Manifests with my own subclasses and generates factories. See: https://github.com/scalagwt/scalagwt-scala/blob/scalagwt/src/compiler/scala/tools/nsc/backend/jribble/FactoryManifestsTransform.scala

Read the comment of the phase to really understand subtle issues. One important thing to notice is the fact that Factories are created for statically known types. This means that GWT can easily generate its matrix because it statically knows all the factories for all possible arrays. Also, it's worth noting that factories support limited level of nesting but this turned out to not be a problem in practice. Entire Scala lib works with those limited factories and some sizeable demos were built on top of them.

The rationale behind introduction of the ArrayBuilder/ArrayFactory was to extract the logic behind Array creation and untie it from other things like reflection. This way on JVM we can provide very straightforward implementation based on reflection that created instances of ArrayFactory and on the other platform (like GWT) we can easily introduce our own implementation + small compiler phase that rewires things (macros are the other alternative).

The reason why this trick works is that wrap is a function ArrayFactory[T] -> ArrayFactory[Array[T]] so it can make use of some internal state of ArrayFactory to implement this operation. With function Class[T] -> Class[Array[T]] our hands are tied. There's no way to add additional state to the Class because Class is final so no tricks with rewiring type alias to a subtype and casting won't work.

To sum up, while I can see appeal of Class-based solution to arrays handling it seems to like it ties array with reflection too much.

--
Grzegorz Kossakowski

[Miles Sabin]

I don't see the problem. The idea is that we have a platform dependent
type alias somewhere,

type Class[T] = java.lang.Class[T]

which would be rebound depending on the target platform. For Scala GWT
it'd be just,

type Class[T] = ArrayFactory[T]

so a wrap function,

Class[T] => Class[Array[T]]

would be,

ArrayFactory[T] => ArrayFactory[Array[T]]

which is exactly what you're after, right?

[Matthew Pocock]

Perhaps this is all to subtle for me, but remember that GWT compiles *the same code* once into js and once into bytecode. I see the attraction of substituting in a different type alias in the two phases, but will this not make everything invoking operations on things typed by this type alias break on one or the other of the compilation phases? If you refer to any operation available on Class then this won't work in the js target, and if you refer to any operation available on ArrayFactory then that won't work in the bytecode target. So, you really do need some interface here to encapsulate this target-specific shim, and given the nature of such things, this interface should have a minimal cross-section and minimal (or absent) coupling to features that may themselves be target-dependent. Of course, under the hood the target-specific implementation of this interface will be very much coupled to the target.

Matthew

--

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

[Grzegorz Kossakowski]

On 22 May 2012 01:24, Matthew Pocock <turingate...@gmail.com> wrote:

Perhaps this is all to subtle for me, but remember that GWT compiles *the same code* once into js and once into bytecode. I see the attraction of substituting in a different type alias in the two phases, but will this not make everything invoking operations on things typed by this type alias break on one or the other of the compilation phases? If you refer to any operation available on Class then this won't work in the js target, and if you refer to any operation available on ArrayFactory then that won't work in the bytecode target. So, you really do need some interface here to encapsulate this target-specific shim, and given the nature of such things, this interface should have a minimal cross-section and minimal (or absent) coupling to features that may themselves be target-dependent. Of course, under the hood the target-specific implementation of this interface will be very much coupled to the target.

Thanks Matthew, well put. That's exactly the issue. 

I cannot replace Class with something completely different because Class itself (along with getName) is supported so that code would break. Also, GWT supports something called "devmode" when it just runs your app on JVM and transmits things like dom calls through RPCs to the browser.

Complecting Class and Array support seems to be a bad idea at least from my point of view.

--
Grzegorz Kossakowski

[Miles Sabin]

On Tue, May 22, 2012 at 12:47 AM, Grzegorz Kossakowski
<grzegorz.k...@gmail.com> wrote:
> I cannot replace Class with something completely different because Class
> itself (along with getName) is supported so that code would break. Also, GWT
> supports something called "devmode" when it just runs your app on JVM and
> transmits things like dom calls through RPCs to the browser.

What currently happens when someone references ClassManifest#erasure?

[Grzegorz Kossakowski]

On 22 May 2012 01:49, Miles Sabin <mi...@milessabin.com> wrote:

On Tue, May 22, 2012 at 12:47 AM, Grzegorz Kossakowski
<grzegorz.k...@gmail.com> wrote:
> I cannot replace Class with something completely different because Class
> itself (along with getName) is supported so that code would break. Also, GWT
> supports something called "devmode" when it just runs your app on JVM and
> transmits things like dom calls through RPCs to the browser.

What currently happens when someone references ClassManifest#erasure?

The java.lang.Class attached to that ClassManifest instance is being returned. The java.lang.Class class itself is stripped down so it doesn't support things like forName but this is not my concern. All this magic is being done by GWT. Fortunately enough, scala library doesn't depend on functionality not supported by GWT (apart from reflective array creation that I solved as outlined).

Why are you asking btw?

--
Grzegorz Kossakowski