Re: [dart-misc] What are symbols in Dart?

[Ladislav Thon]

Whar is purpose of Symbol type?

It is "Opaque name used by mirrors, invocations and Function.apply".

It's all?

Yes. As far as I know, yes. It has nothing in common with Ruby symbols.

I'd actually prefer if it was called Identifier. Or something like that.

LT

[Ladislav Thon]

The discussion only about Dart Symbol type.

1. What are real purpose?

http://news.dartlang.org/2013/04/goodbye-invocationmirror-hello.html

 

2. Will be added new built-in type or not?

http://dartbug.com/9972

LT

P.S.: There are no built-in types. There are only literals for some of the classes in dart:core.

[Kai Sellgren]

On Thursday, April 18, 2013 10:36:31 AM UTC+3, mezoni wrote:

>> There are only literals for some of the classes in dart:core.

Sorry, but you're talking about things that you do not understand.

Sorry, but you're being a bit rude to him. :) 

[Ladislav Thon]

>> Sorry, but you're being a bit rude to him. :) 

I highly respect him. Honest.

Ladislav, my friend, I'm sorry. You're doing fine.

Don't worry, it's just tech :-)

And by the way, I really think that Dart has nothing like "built-in" types. As in, the language depends on some types being present in dart:core, but it doesn't fully define their behavior -- that's left for the library. And I like it this way. I actually like a LOT of Dart design desicions.

LT

[Gen]

Am Donnerstag, 18. April 2013 14:54:48 UTC+2 schrieb mezoni:

>> Sorry, but you're being a bit rude to him. :) 

I highly respect him. Honest.

Ladislav, my friend, I'm sorry. You're doing fine.

lol :)
Yes, he is still alive.

[Peter Ahé]

On Thu, Apr 18, 2013 at 10:19 AM, mezoni <andrew...@gmail.com> wrote:
> 3. Where is the truth and where is false?

I expect this will be discussed in future language meetings.

Bob frequently posts the notes from the language meetings on this list.

Personally, I don't expect we'll have a literal syntax for symbols in
Dart 1.0. But who knows what happens later.

Cheers,
Peter

[Bob Nystrom]

On Thu, Apr 18, 2013 at 7:41 AM, Peter Ahé <a...@google.com> wrote:

I expect this will be discussed in future language meetings.

Possibly, but it's worth keeping in mind that many of the language design discussions and decisions happen outside of those meetings. When that happens, there rarely seems to be any documentation associated with it.

- bob

[Peter Ahé]

The discussion outside the language meetings that I'm aware of, can be summarized as:

In the red corner: the mirror API will be horrible to use without literal syntax for symbols.

In the blue corner: the mirror API, although important, is just one library amongst many, and as such doesn't warrant dedicated syntax. Unless symbols are used pervasively throughout general Dart programs, literal syntax seems excessive.

I'm not sure where I stand right now, but if we decide to add symbol literals, I'd prefer if we postpone them until after 1.0. 

Cheers,

Peter

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

[Ladislav Thon]

> In the red corner: the mirror API will be horrible to use without literal syntax for symbols.
>
> In the blue corner: the mirror API, although important, is just one library amongst many

It's the only way we can do meta-programming, no? I think that this qualifies mirrors a little above the other libraries.

> Unless symbols are used pervasively throughout general Dart programs, literal syntax seems excessive.

Can we translate this to "unless meta-programming is used pervasively throughout general Dart programs, ..."?

LT

[Craig R Ewert]

Nice summation.

How many users of symbols do you expect?  Only debuggers and such?

In the green corner, perhaps that horrible map syntax to make a symbol map points to a shortfall in map literals in general. I'd pay for a cleaner way to make general map literals, and all literals.

[Craig R Ewert]

I'd call that a good translation.  And as 1data point, I don't meta-program or reflect every day. I only rarely do those things.

--

[Peter Ahé]

I'm not sure. The literals are only useful when you can write "const Symbol". We'll have too see how often that is. I'm not sure I can translate my experience from Smalltalk/Newspeak in this situation. So I truly don't know what to expect. 

Cheers,

Peter

 

LT

[Alex Tatumizer]

Symbol, as currently defined, implements the same interface as null.
Which means that null is a Symbol.

I am not a language designer, but had I been one, I would be very tempted to take advantage of this :-)
(charmed null?)

[Alex Tatumizer]

Warning: rant ahead!

Symbols, as currently defined for the purposes of passing names to mirrors, have another interesting property: they are enumerated values.
Definition of every class provides fixed (*) set of method names - it's an implicit enumeration.

When we have method "foo" in class A, and method "foo" in class B, we can still pass THE SAME instance of const Symbol("foo") to both mirrors.
This is remarkable. We don't have to "disambiguate" anything like const Symbol("A.foo") or  const Symbol("B.foo") - because Symbol foo will be interpreted in a context of A or B anyway, depending on invocation.

Why situation should be different for other enums? If we introduce literal #foo for const Symbol("foo"), why literal #Green cannot play the same role in other enumerations as #foo plays in mirrors? Why should we write it as Color.GREEN or COLOR_GREEN or something? Just #Green is enough - it will be disambiguated by a function that receives this symbol as parameter!

Another curious observation is that (as we noted above) null is certainly a symbol, but very badly defined one. It's a blanket name for a number of completely different things: #NotInitialized, #NotKnown, #NotFound, #DoesNotMatter, #UseDefault etc.
I think life would be easier if this distinction was made more explicit. All of those a just different flavors of null (as any other symbol).

(*) methodNotFound is an exception, let's forget about it for now.

[Ladislav Thon]

Why situation should be different for other enums? If we introduce literal #foo for const Symbol("foo"), why literal #Green cannot play the same role in other enumerations as #foo plays in mirrors?

Because after minification, the symbol will have a completely different string value.

LT

[Alex Tatumizer]

>Because after minification, the symbol will have a completely different string value.

So what? They will all be replaced consistently everywhere. Program is not supposed even to treat it as string value.

I don't understand this argument: situation in mirrors is the same: reflection has to use a map  from symbol to function. Symbol, even after its "string value" is minified, points to the same function.

I admit I don't know enough about problems of minification, but on the first glance, I can't see how this makes any difference.

On Fri, Apr 19, 2013 at 12:02 PM, mezoni <andrew...@gmail.com> wrote:

>> because Symbol foo will be interpreted in a context of A or B anyway, depending on invocation.

I don't understand.

Symbols captured the context when them instantiated?

I.e. symbols with the same signature but created in different places will be diffirent?

Which information them captured on instantiation?

Information about library, class and method?

What happened if symbol wil be passed incorrectly?

Which error handling will be provided for this situations?

Or will it be on the conscience of a programmer?

[Alex Tatumizer]

It would be good to have some blog post about inner workings of minification algo.

E.g. somebody said the map is not transferred to client. Then... how it works when, like in mezoni's example, somebody tries to create Symbol on client : new Symbol(str). System certainly should look it up in a map of some kind, right?

On Fri, Apr 19, 2013 at 1:40 PM, mezoni <andrew...@gmail.com> wrote:

I apologize for such questions. It is not rude. I just want to understand the meaning.

[Ladislav Thon]

E.g. somebody said the map is not transferred to client. Then... how it works when, like in mezoni's example, somebody tries to create Symbol on client : new Symbol(str). System certainly should look it up in a map of some kind, right?

If you do new Symbol, then the mapping between original names and minified names must be transferred to the client, yes. If everything you do is const Symbol, then the compiler is able to resolve everything at the compile time.

LT

[Ladislav Thon]

Dart is not pure object oreiented programming language.

Everything is an object in Dart. What else do you mean?

LT

[Ladislav Thon]

Class in dart is object of class Class (or object of other class)?

Library in dart is object of class Library (or object of other class)?

You are right, as far as the language is concerned, not all language features are objects at runtime. Sorry about that.

But if you take a look inside the VM, the answer to both these questions would in fact be yes. It's an implementation detail, of course -- you can't access these objects directly, only via mirrors. That's a leading principle behind metaprogramming in Dart -- it's completely separated from base level.

LT

[Ladislav Thon]

>> That's a leading principle behind metaprogramming in Dart -- it's completely separated from base level.

You are mistaken.

At the moment the Dart is not a metaprogramming language because no one main principle of Metaprogramming can be found in Dart.

Oh yes it can.

 

1. Dart does not support evaluating expression at runtime (eval).

Yes it does. Evaluating expressions at runtime doesn't necessarily mean that there has to be an eval function that takes a string -- there are other approaches that are functionally equivalent. Reflection, for example. It is of course possible to implement eval by hand.

LT

[Davy Cielen]

Because the documentation on the Symbols class is rather sparse, I have written a layman introduction into Symbols here link. Because I am not an expert I would appreciate some feedback, corrections, ... so that we can help other DART users.

Thank you,

Davy

Op donderdag 18 april 2013 08:02:21 UTC+2 schreef mezoni het volgende:

What are symbols in Dart?

From Dart API reference guide: http://api.dartlang.org/docs/releases/latest/dart_core/Symbol.html

Symbol class

Opaque name used by mirrors, invocations and Function.apply.

I.e. the folllowing statements is true.

1. Symbol is not the built-in type.

2. Symbol is the classified type.

Whar is purpose of Symbol type?

It is "Opaque name used by mirrors, invocations and Function.apply".

It's all?

Or there something else?

-----------------

From Ruby language.

What are symbols?

It's a string. No it's an object. No it's a name.

A Ruby symbol is a thing that has both a number (integer) representation and a string representation.

What are symbols not?

A Symbol is Not a String.

And so on...

-----------------

There is already a proposal in Dart for the introduction of separate presentation for the values ​​of Symbol type.

Like this (`foo`) or (#foo).

In other words, the proposal to introduce a new built-in type in the grammar of the language.

[John Messerly]

On Sat, Apr 20, 2013 at 3:53 AM, mezoni <andrew...@gmail.com> wrote:

Ladislav, please, answer me.

Dart is class-based language and object oriented.

1. Object is an instance of class?

yes

 

2. What means term "class" in Dart?

see: Type in dart:core, TypeMirror in dart:mirrors

 

3. Where classes stored?

4. How classes can be obtained and used in Dart?

Object.runtimeType, reflectClass in dart:mirrors, reflect in dart:mirrors

 

5. What means object of class XXX?

This can be found in the language spec.

[John Messerly]

See the language spec I linked earlier; it has the specification for the Dart language.

On Tue, Apr 23, 2013 at 2:04 PM, mezoni <andrew...@gmail.com> wrote:

2. What means term "class" in Dart?

>> see: Type in dart:core, TypeMirror in dart:mirrors

---------------

From Type in dart:core

Type abstract class

Runtime representation of a type.

I.e. Abstract class type is runtime representation of a type (another type that not runtime).

The documentation is not sufficient.

I don't know what means "another type that not runtime" which Abstract class type represent at runtime.

---------------

From TypeMirror in dart:mirrors

TypeMirror abstract class

A TypeMirror reflects a Dart language class, typedef, or type variable.

Well. A TypeMirror reflects a Dart language class.

May be you explain me what is a Dart language class?

Or may be you explain me what is a class in Dart language?

Or may be simple? What is a class?

With you are all clear.

1. Class is something that reflects TypeMirror.

2. A TypeMirror reflects a Dart language class.

What is a class?

See #1.

---------------

Abraham, where you take the money?

In a box.

And in a box where they come from?

Wife puts them there.

And the wife where takes money?

I give her.

Where do you get the money?

In a box.

And in a box where they come from?

Wife puts them there.

...

[Ladislav Thon]

> How TypeMirror or ClassMirror acn reflects on something that in reality does not exist?

It's this simple: it DOES exist (both as a concept in the language specification and as an object in Dart implementation), but you can't access it directly. You can only interact with it using its mirror.

So yes, this is more similar to Java than to SmallTalk, but there are obvious reasons: performance, safety and good engineering practice.

> Mirror involves reflection.
> If you go to the mirror you see your reflection.
>
> What reflects TypeMirror or ClassMirror?
> Ghost? Vampire?

They are normal objects of normal classes, so you can reflect on them using normal reflection. Therefore, if you have an object of class ClassMirror and you reflect on it, you will get an InstanceMirror, which of course has its own ClassMirror.

> Where is the source of reflection?

God. Or the laws of physics. Or, tadaa, the dart:mirrors library. It isn't in the language, it's completely defined by the library -- which is also why you can completely forbid reflection, if you embed the Dart VM in your own program. (Yes, you can do that, and yes, it can be useful.)

LT

P.S.: what exactly are you trying to prove here? The fact that Dart isn't SmallTalk? We all know that.

[Peter Ahé]

On Wednesday, April 24, 2013, Ladislav Thon wrote:

> How TypeMirror or ClassMirror acn reflects on something that in reality does not exist?

It's this simple: it DOES exist (both as a concept in the language specification and as an object in Dart implementation), but you can't access it directly. You can only interact with it using its mirror.

So yes, this is more similar to Java than to SmallTalk, but there are obvious reasons: performance, safety and good engineering practice.

Actually, Smalltalk (notice proper case :-) and Java made the same mistakes when it comes to reflection. Dart is more similar to Self than it is to Java in this case.

See Gilad's paper on this topic: http://bracha.org/mirrors.pdf

But the class of an object in Dart is a very limited thing (an instance of Type). Static member are not instance members on that object, static members are best understood as top level members that are defined in a namespace (a class).

You might expect that the class object (an instance of Type) is a factory object that has factory methods corresponding to the constructors and factories defined in the class. But that isn't the case either.

In fact, all the class object (which is an instance of Type) does is serve as a key to the mirror system. You have to use the mirror system to perform reflective operations, and in that aspect Dart is different from Java and Smalltalk. Furthermore, Dart has a fairly low bar for what is considered a reflective operation. In that aspect, Dart is different from Smalltalk and JavaScript.

These choices are part of why Dart is so fast compared to, for example, JavaScript. In Dart we know when a static method is invoked. We know that it isn't going to change as it might in JavaScript.

We can statically analyze a Dart program and compile it to efficient JavaScript because an operation like Smalltalk's perform isn't found in the core library.

So yes, Dart is different from all the languages that inspired it. For good reasons, mostly :-)

Cheers,

Peter

> Mirror involves reflection.
> If you go to the mirror you see your reflection.
>
> What reflects TypeMirror or ClassMirror?
> Ghost? Vampire?

They are normal objects of normal classes, so you can reflect on them using normal reflection. Therefore, if you have an object of class ClassMirror and you reflect on it, you will get an InstanceMirror, which of course has its own ClassMirror.

> Where is the source of reflection?

God. Or the laws of physics. Or, tadaa, the dart:mirrors library. It isn't in the language, it's completely defined by the library -- which is also why you can completely forbid reflection, if you embed the Dart VM in your own program. (Yes, you can do that, and yes, it can be useful.)

LT

P.S.: what exactly are you trying to prove here? The fact that Dart isn't SmallTalk? We all know that.

--

[Ladislav Thon]

> How TypeMirror or ClassMirror acn reflects on something that in reality does not exist?

It's this simple: it DOES exist (both as a concept in the language specification and as an object in Dart implementation), but you can't access it directly. You can only interact with it using its mirror.

So yes, this is more similar to Java than to SmallTalk, but there are obvious reasons: performance, safety and good engineering practice.

Actually, Smalltalk (notice proper case :-)

Doh! Sorry, guys :-)

 

and Java made the same mistakes when it comes to reflection. Dart is more similar to Self than it is to Java in this case. 

See Gilad's paper on this topic: http://bracha.org/mirrors.pdf

You're speaking about the main principles behind mirrors, right? The fact that meta-level is separated from base-level and such. I was speaking more about the fact than in Java, you only get a reflective access to the class (a very limited one, that is), while in Smalltalk, classes are normal objects. Which seems to be what this thread is all about.

But thanks for your insight. It's always appreciated -- my understanding is severely limited in this area :-)

LT

[Peter Ahé]

On Wednesday, April 24, 2013, Ladislav Thon wrote:

> How TypeMirror or ClassMirror acn reflects on something that in reality does not exist?

It's this simple: it DOES exist (both as a concept in the language specification and as an object in Dart implementation), but you can't access it directly. You can only interact with it using its mirror.

So yes, this is more similar to Java than to SmallTalk, but there are obvious reasons: performance, safety and good engineering practice.

Actually, Smalltalk (notice proper case :-)

Doh! Sorry, guys :-)

 

and Java made the same mistakes when it comes to reflection. Dart is more similar to Self than it is to Java in this case. 

See Gilad's paper on this topic: http://bracha.org/mirrors.pdf

You're speaking about the main principles behind mirrors, right? The fact that meta-level is separated from base-level and such.

Yes. I'm trying to explain that the picture is more complicated.

 

I was speaking more about the fact than in Java, you only get a reflective access to the class (a very limited one, that is), while in Smalltalk, classes are normal objects. Which seems to be what this thread is all about.

In Dart, classes are objects just like they are in Java and Smalltalk. However, the three languages have a different take on what methods these objects have.

Unlike Java, Dart has no values that aren't objects. In Dart, even classes are objects, but their implementation details are hidden and can only be examined through the mirror system.

I think that "everything is an object" is an important property of a true object-oriented language. Dart, Smalltalk, and Self are all true to that. Java and JavaScript are not.

My opinion is that how you interact with the objects is besides the point, as long as they are objects.

Cheers,

Peter

 

But thanks for your insight. It's always appreciated -- my understanding is severely limited in this area :-)

LT

--

[Peter Ahé]

The expression "Object" in Dart gives you a class object which has the type "Type".

Just because this object implements "Type" doesn't mean it isn't a class. But the presence of type arguments muddies the picture a bit. This means that "x.runtimeType" doesn't always produce a class object. 

The unfortunate thing is that you could get the impression that objects that implement "Type" are types, but they aren't. We just lack a better word to describe them.

Why aren't they types? Because they cannot be used as types:

Type T = String;

class Foo implements T {} // Warning: T is not a type. 

T x = ""; // Warning: T is not a type.

main() {

  "" is T; // Warning: T is not a type. 

  "" as T; // Warning: T is not a type.

}

Some people have a tendency to say "type" when they mean "class", "interface", or "constructor function". This adds to the confusion.

Cheers,

Peter

On Wednesday, April 24, 2013, mezoni wrote:

>> Unlike Java, Dart has no values that aren't objects.

>> In Dart, even classes are objects, but their implementation details are hidden and can only be examined through the mirror system.

A small correction.

Type (not a class) implementation details are hidden and can only be examined through the mirror system.

In the Dart runtime there is no classes (nor hidden nor visible).

Only types.

Classes in Dart only the form and behavior of a set of objects which are its instances.

Also, I do not argue reflestion is present.

P.S.

How implemented _Type (RuntimeType) I would be ashamed to even mention it.

It's just a circus.

Also name "Symbol" for example, is slightly embarrassing.

"ReflectionLink" are more meaningful.

[Lasse R.H. Nielsen]

I'd say that classes are not objects in Dart.

When I write "new Foo()" or "Foo.someStatic()" or "x is Foo", I use the name "Foo" to refer to a class.

I can do all these things with the class. However, that class is not an object - it's not even a value. The real class is denotable, but not expressible as a value.

When I write "var f = Foo;", I get a value that is not the class. I can't say "new f()" or "f.someStatic()" or "x is f", like I can with the real class, so the object I have is not the same as the class.

It is an object that represents the class - a reflection of the real class into an expressible value that I can operate on as data.

There is currently no way to reify the class, no syntax I can write to do "new Reify<f>()". Instead I can reflect the operations as well, using mirrors - so I can ask the ClassMirror for Foo (which I create using the "f" value to represent Foo to the mirror system) to create a new instance.

In Dart, all values are objects. Not all Dart concepts are values.

/L

On Wed, Apr 24, 2013 at 12:24 PM, mezoni <andrew...@gmail.com> wrote:

>> Unlike Java, Dart has no values that aren't objects.

>> In Dart, even classes are objects, but their implementation details are hidden and can only be examined through the mirror system.

A small correction.

Type (not a class) implementation details are hidden and can only be examined through the mirror system.

In the Dart runtime there is no classes (nor hidden nor visible).

Only types.

Classes in Dart only the form and behavior of a set of objects which are its instances.

Also, I do not argue reflestion is present.

P.S.

How implemented _Type (RuntimeType) I would be ashamed to even mention it.

It's just a circus.

Also name "Symbol" for example, is slightly embarrassing.

"ReflectionLink" are more meaningful.

--

Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

--
Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Ladislav Thon]

In Dart, all values are objects. Not all Dart concepts are values.

Exactly. And if we are not sure about classes, then definitely libraries are not objects. (Even though in Dart VM, they internally are :-) )

LT

[Peter Ahé]

Lasse,

As I understand your argument, you're looking at this example:

var f = Foo;
new f();

Then you say, the value stored in f isn't a class because the new
expression doesn't work. So you expect certain things of a class
object, and it seems if your expectations aren't met, the object in
question cannot be a class. I disagree with this.

I'm arguing that an object that cannot do much else but act as key to
the mirror system can still be a class object. It is a matter of
perspective. As far as I know, this is an ancient philosophical
debate.

If you insist on thinking of this as "not a class", please go ahead,
but this is not what I find the most intuitive way of describing what
value f is holding in the above example.

On Wed, Apr 24, 2013 at 4:36 PM, Lasse R.H. Nielsen <l...@google.com> wrote:
> I'd say that classes are not objects in Dart.
>
> When I write "new Foo()" or "Foo.someStatic()" or "x is Foo", I use the name
> "Foo" to refer to a class.
> I can do all these things with the class. However, that class is not an
> object - it's not even a value. The real class is denotable, but not
> expressible as a value.
> When I write "var f = Foo;", I get a value that is not the class. I can't
> say "new f()" or "f.someStatic()" or "x is f", like I can with the real
> class, so the object I have is not the same as the class.
> It is an object that represents the class - a reflection of the real class
> into an expressible value that I can operate on as data.
>
> There is currently no way to reify the class, no syntax I can write to do
> "new Reify<f>()". Instead I can reflect the operations as well, using
> mirrors - so I can ask the ClassMirror for Foo (which I create using the "f"
> value to represent Foo to the mirror system) to create a new instance.
>
> In Dart, all values are objects.

Yes. More precisely, I could have said: "All expressions in Dart
evaluate to objects".

> Not all Dart concepts are values.

Agreed. In particular, we have no value directly representing a library.

Cheers,
Peter

[Ladislav Thon]

> Why you post this example?

>
> var f = Foo; 
> new f(); 

> This is impossible. Or it return the same Foo.
>
> But this is possible in other languages.
>
> var stringClass = String;
> var  stringValue = stringClass.createInstance('Hello');

var stringClass = String;
var stringValue = reflectClass(stringClass).newInstance(const Symbol(''), ['Hello']);

Well, this doesn't work as the String class doesn't have a copy constructor, but you get the idea.

LT