Demystifying Symbols.

[Donkey Agony]

Reading Gavin's post and Jim's blog article dropped a new metaphor
into my head, one that, the more I test it out, the more I like it.

I missed Jim's blog earlier, but I just read it now. Very interesting,
and it clued me in on some key points. But ... he lists three points:
points 1 and 2 are clear; point 3 flew right over my head:

<quote>
1. The distinction between immediate values (like Fixnum) and reference
values (most everything else) becomes invisible.

2. Multiple assignment statements (like 'a = b = "Hello"') is explained
in terms of binding the names 'a' and 'b' to the same object. No need to
talk about pointers or references.

3. Assignment becomes an operation that is outside an object. Objects
don't care what names they are bound to. Therefore binding is not an
operation on an object and won't ever be a method on an object. This
helps explain why "+=" is not a method and why "++" can't be implemented
as a method.
</quote>

In point 3, I don't understand the "therefore ...", nor do I understand
why += is not a method and ++ can't be implemented as one. (That seems
to mean that += *could* be one but for some good reason isn't?)

 

[Alex Combas]

I'll be honest, as a rubynewbie I liked Jim's description of variables
better than any other description I've heard here so far,
and I'm going to go read his post on symbols and
see if that jives with me as well.

Jim's definition:
Variables are like dictionary definitions bound to an object.
VarA =3D VarB =3D ObjectZ

Explanation:
If you looked up the definition of VarA in our dictionary it would say 'Obj=
ectZ'
and likewise if you looked up the definition for VarB in our
dictionary it would say 'ObjectZ'.

No, pointer, no container, no pigeon hole or shoebox.. just a strait forwar=
d
term bound to a definition.

This maps nicely to the real world where you can look up the word 'house ca=
t'
in a dictionary and find that it maps to 'small domesticated
carnivorous mammal', the cat
doesn't 'point' to a carnivore in a pigeon hole, and it doesn't
'contain' a carnivore in a shoebox. 'House cat' is simply a term bound
to a definition in our dictionary.

In this dictionary more than one variable is permitted to be bound to
the same object:
small_dog =3D house_cat =3D 'small domesticated carnivorous mammal'

In a real dictionary terms are bound to descriptions, but in the ruby
dictionary
of variables we would say terms are bound to objects, this boils down
to exactly the same thing.

Grok?

 

[Lyndon Samson]

------=_Part_77945_8263137.1136705001200
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

...

In this dictionary more than one variable is permitted to be bound to

the same object:
small_dog =3D house_cat =3D 'small domesticated carnivorous mammal'

In a real dictionary terms are bound to descriptions, but in the ruby
dictionary
of variables we would say terms are bound to objects, this boils down
to exactly the same thing.

Grok?

Seems pretty static and the emphasis is on the underlying objects
independant existence, which of course is very much
dependant on some live reference or it will be GC'd.

How would you explain?

a=3Da+1

Anyone who has written or studied the source code to an assembler knows the
basics of symbols.

Symbol Table
Id Table/Array
1 "word1"
2 "word2"
3 "word3"

Thus in some simple pseudo assembler

loads R1,"word1"
loads R2,"word2"
loads R3,"word1"

assembles to

loads 1,1
loads 2,2
loads 3,1

All new symbols are added to the symbol table, and symbols are only ever
referenced by Id. I'd guess that most modern VM's would behave in a similar
manner.






--

 

[Alex Combas]

How would you explain?

a=3Da+1

I don't know if this is what you are looking for, but this is how I
would explain:

Remember the variable 'a' is only a term.
Terms are bound to objects, and we find out which term
to which object by looking them up in a dictionary.

When we make a request (such as: a =3D a+1) for ruby to do
some operations with a variable ruby will do a quick look-up
in its dictionary to see which object is currently bound to that
term and then attempt to do whatever operations we have requested
upon on the object to which the term is bound.

I think this is somewhat similar to your assembler example.