Mutable strings

M

Mystifier

------=_NextPart_000_000A_01C4F9CE.A35BD420
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,
=20
Since my communications skills have be questioned on the ML, I am trying =
to
be better :)
=20
=20
I saw few last posts by matz categorically saying that strings shall be
mutable.=20
=20
I have nothing against or for it as a language specification. What =
interests
me that if string are immutable, we can use strings as symbols. This can
bring about few important effects on VM.
=20
1) Symbols and FixNum have few exceptions to the usual rules. Symbols =
may
not have any exceptions, since symbol and strings will be basically =
same.
=20
2) Efficiency of VM will improve because Symbols and Strings can be used
interchangeably.
=20
3) It might help on security, perhaps.
=20
A Mutable string class can be created for mutating strings.
=20
No, I am not trying to create another java, but as Users, how many times
have you mutated your strings?
=20
A mailing list to discuss Vuby Specifications has been created on =
Berlios
and will be active shortly for discussions.
=20
https://developer.berlios.de/projects/vuby/
=20
regards,
Mystifier
=20

------=_NextPart_000_000A_01C4F9CE.A35BD420--
 
A

Austin Ziegler

Hi All,

Since my communications skills have be questioned on the ML, I am trying to
be better :)

I saw few last posts by matz categorically saying that strings shall be
mutable.

I have nothing against or for it as a language specification. What interests
me that if string are immutable, we can use strings as symbols. This can
bring about few important effects on VM.

"Foo Bar".to_sym
:"Foo Bar".to_s

-austin
 
C

Charles Mills

Mystifier said:
Hi All,

Since my communications skills have be questioned on the ML, I am trying to
be better :)


I saw few last posts by matz categorically saying that strings shall be
mutable.

I have nothing against or for it as a language specification. What interests
me that if string are immutable, we can use strings as symbols. This can
bring about few important effects on VM.

1) Symbols and FixNum have few exceptions to the usual rules. Symbols may
not have any exceptions, since symbol and strings will be basically
same.

Symbols are immutable. The current implementation of symbols seems
like a good one to me. They are just a number that uniquely identifies
a string (contained in a symbol table somewhere in the interpreter).
2) Efficiency of VM will improve because Symbols and Strings can be used
interchangeably.
Ruby already uses some nice tricks for sharing memory between string
instances (and between array instances).
3) It might help on security, perhaps.

A Mutable string class can be created for mutating strings.

No, I am not trying to create another java, but as Users, how many times
have you mutated your strings?

Try ri String. About 1/2 the methods change the reciever.
A mailing list to discuss Vuby Specifications has been created on Berlios
and will be active shortly for discussions.

https://developer.berlios.de/projects/vuby/

There are already a number of Ruby VM projects. Many of them
relatively mature. Perhaps you should take a look at those.
If you are writing a VM, I don't see why you would need to rewrite the
standard library, or even break the Ruby API at the C level.

-Charlie
 
N

Nikolai Weibull

* Mystifier (Jan 13, 2005 19:50):
I have nothing against or for it as a language specification. What
interests me that if string are immutable, we can use strings as
symbols. This can bring about few important effects on VM.

Python has immutable strings. If you want 'em, use Python.

Now, lets begin a long thread about Python versus Ruby, starting off by
discussing the merits of immutable versus mutable strings, but soon
trailing off by discussing the fact that Guido is Dutch and matz is
Japanese and how this makes Python/Ruby better/worse,
nikolai
 
M

Mystifier

Dear Charles,

I have no intensions of changing the language APIs for it really does not
matter to a VM Implementation. All the components that inherently affects
the VM implementations are those that VM uses natively like File, Strings,
Numbers and Threads.

I surprisingly found Symbols are exactly not Immutable...., they are just
like any other class

irb(main):001:0> foo = :foo
=> :foo
irb(main):002:0> class Symbol
irb(main):003:1> def bar=(value)
irb(main):004:2> @bar = value
irb(main):005:2> end
irb(main):006:1> def printbar
irb(main):007:2> print @bar
irb(main):008:2> end
irb(main):009:1> end
=> nil
irb(main):010:0> foo.bar = "eee"
=> "eee"
irb(main):011:0> foo.printbar
eee=> nil
irb(main):012:0> zoo = :foo
=> :foo
irb(main):013:0> zoo.printbar
eee=> nil
irb(main):014:0>

We can think that keys that are strings of the Symbol table are immutable,
while the values which are objects of the instances Symbol are mutable. I
had thought that symbol table was a hash_set but it turns out that it is a
hash_map.

In that case it appears immutable strings are be called as symbols and Ruby
has Immutable strings. of course, by implementing additional methods.

Regards,
Mystifier
 
R

Robert Klemme

I saw few last posts by matz categorically saying that strings shall be
mutable.

I have nothing against or for it as a language specification. What interests
me that if string are immutable, we can use strings as symbols. This can
bring about few important effects on VM.

1) Symbols and FixNum have few exceptions to the usual rules. Symbols may
not have any exceptions, since symbol and strings will be basically
same.

Do you mean that the current restrictions of Symbol will no longer apply?
2) Efficiency of VM will improve because Symbols and Strings can be used
interchangeably.

Not necessarily: you can see with a Java VM that efficiency of the
application degrades if you have many string manipulations that use String
instead of a more suited class (StringBuffer for example). The same will
happen in Ruby if you need to create a new object for each mutated string.
3) It might help on security, perhaps.

Ruby has already #freeze and $SAFE. What additional security do we gain?
A Mutable string class can be created for mutating strings.

I don't understand what we gain by this. We have this situation already:

- Symbols and frozen Strings are immutable

- Other Strings are mutable

With the added benefit that Symbols are unique: there is at most one
Symbol instance representing a certain character sequence.
No, I am not trying to create another java, but as Users, how many times
have you mutated your strings?

Often enough to say it's a very common scenario.

Regards

robert
 
F

Florian Gross

Mystifier said:
I surprisingly found Symbols are exactly not Immutable...., they are just
like any other class

They are mostly immutable. I'd still consider them value objects. In
Ruby you can set instance variables of all Objects, even if they're
immutable.
 
A

Austin Ziegler

Dear Charles,

I have no intensions of changing the language APIs for it really
does not matter to a VM Implementation. All the components that
inherently affects the VM implementations are those that VM uses
natively like File, Strings, Numbers and Threads.

I surprisingly found Symbols are exactly not Immutable...., they
are just like any other class

Um. That's not the same at all. Symbols themselves are immutable.
The Symbol Class is not immutable.

Yes, this means that someone could override #to_s on Symbol to do
something else entirely, but Symbols themselves are immutable -- and
they cannot have virtual (singleton) classes:

irb(main):001:0> foo = :foo
=> :foo
irb(main):002:0> class << foo
irb(main):003:1> end
TypeError: no virtual class for Symbol
from (irb):2
irb(main):004:0>

There is a significant difference between the two sorts of
immutability that you would be advised to understand before even
thinking of attempting to implement a VM to support Ruby.

-austin
 
A

Austin Ziegler

No, I am not trying to create another java, but as Users, how many
times have you mutated your strings?

All the time.

I'm working on Text::Format again to get it cleaned up for a 1.0
release, and it does:

line << " " if sentence_end and extra_space
line << " #{next_word}"

There's your mutable strings. They are a necessary component of most
languages that do a lot of string manipulations. (Most of my
projects end up doing quite a bit of string manipulation; Ruwiki
uses a lot of gsub! calls, no less.)

-austin
 
M

Mystifier

Dear Austin,

Immutability as I understand is preserving state of the Object. State of
Object are instance variables in Ruby. My example does sot change class
variables, but the instance variable. Symbol class being immutable or not is
besides the point. I am talking about symbol instance, and ability to change
symbol instance variables makes them not immutable as such. Yes, the
sequence of chars they represent are immutable. Hence, I get an impression
that the Symbol is a immutable string class.

About learning things before writing VM, I am sure I have to. What I feel No
VM or Interpreter can exists with reasonable performance with have an
immutable string class. It is altogether a different matter what you call
them.



-----Original Message-----
From: Austin Ziegler [mailto:[email protected]]
Sent: Friday, January 14, 2005 7:59 PM
To: ruby-talk ML
Subject: Re: Mutable strings


Dear Charles,

I have no intensions of changing the language APIs for it really does
not matter to a VM Implementation. All the components that inherently
affects the VM implementations are those that VM uses natively like
File, Strings, Numbers and Threads.

I surprisingly found Symbols are exactly not Immutable...., they are
just like any other class

Um. That's not the same at all. Symbols themselves are immutable. The Symbol
Class is not immutable.

Yes, this means that someone could override #to_s on Symbol to do something
else entirely, but Symbols themselves are immutable -- and they cannot have
virtual (singleton) classes:

irb(main):001:0> foo = :foo
=> :foo
irb(main):002:0> class << foo
irb(main):003:1> end
TypeError: no virtual class for Symbol
from (irb):2
irb(main):004:0>

There is a significant difference between the two sorts of immutability that
you would be advised to understand before even thinking of attempting to
implement a VM to support Ruby.

-austin
 
A

Austin Ziegler

Immutability as I understand is preserving state of the Object.
State of Object are instance variables in Ruby. My example does
sot change class variables, but the instance variable. Symbol
class being immutable or not is besides the point. I am talking
about symbol instance, and ability to change symbol instance
variables makes them not immutable as such. Yes, the sequence of
chars they represent are immutable. Hence, I get an impression
that the Symbol is a immutable string class.

Yes. The intrinsic value of a symbol is immutable -- and it doesn't
have support for virtual classes; the fact that it's an Object like
everything else, though, says that it can have additional methods or
even instance variables added at any time.
About learning things before writing VM, I am sure I have to. What
I feel No VM or Interpreter can exists with reasonable performance
with have an immutable string class. It is altogether a different
matter what you call them.

And I think that the existence of Ruby -- which is quite performant
for a lot of people -- suggests otherwise.

-austin
 
R

Robert Klemme

That statement is far too general IMHO. There are a lot more factors that
affect VM performance. And a fast VM still does not guarantee fast
program execution...

Cheers

robert
 
M

Mystifier

About learning things before writing VM, I am sure I have to. What I
Clarification:
It says that immutable string class is necessary in VM because instead of
comparing strings for method names etc in VM you can use integers or
references comparison. Ruby also does same thing but for Unknown reasons
prefers to call them symbol class and not an immutable string class. They
want to deny that Ruby has any. I have found Symbol has all the ingredients
of immutable string class. It has something more - uniqueness.

Mystifier
 
T

ts

M> references comparison. Ruby also does same thing but for Unknown reasons
M> prefers to call them symbol class and not an immutable string class. They
M> want to deny that Ruby has any. I have found Symbol has all the ingredients
M> of immutable string class. It has something more - uniqueness.

Read this message [ruby-talk:113107]


Guy Decoux
 
M

Mystifier

Thanks.

Should messages like this be mailing posts or personal posts?

Mystifier

-----Original Message-----
From: ts [mailto:[email protected]]
Sent: Friday, January 14, 2005 11:21 PM
To: ruby-talk ML
Cc: (e-mail address removed)
Subject: Re: Mutable strings


M> references comparison. Ruby also does same thing but for Unknown
M> reasons prefers to call them symbol class and not an immutable string
M> class. They want to deny that Ruby has any. I have found Symbol has
M> all the ingredients of immutable string class. It has something more
M> - uniqueness.

Read this message [ruby-talk:113107]


Guy Decoux
 
T

trans. (T. Onoma)

On Friday 14 January 2005 12:59 pm, Mystifier wrote:
| Thanks.
|
| Should messages like this be mailing posts or personal posts?

Mailing posts I would think though I sure would like it if an actual link was
provided.

T.
 
M

Mystifier

Uff! I did it again. Need to go to school back!

Sorry, I meant small messages like thanking you for the link etc be posted
on personal mail or on this mailing list.

Mystifier

-----Original Message-----
From: trans. (T. Onoma) [mailto:[email protected]]
Sent: Friday, January 14, 2005 11:35 PM
To: ruby-talk ML
Subject: Re: Mutable strings


On Friday 14 January 2005 12:59 pm, Mystifier wrote:
| Thanks.
|
| Should messages like this be mailing posts or personal posts?

Mailing posts I would think though I sure would like it if an actual link
was
provided.

T.
 
N

Nikolai Weibull

* Mystifier (Jan 14, 2005 18:40):
Clarification: It says that immutable string class is necessary in VM
because instead of comparing strings for method names etc in VM you
can use integers or references comparison. Ruby also does same thing
but for Unknown reasons prefers to call them symbol class and not an
immutable string class. They want to deny that Ruby has any. I have
found Symbol has all the ingredients of immutable string class. It has
something more - uniqueness.

Ruby doesn't have an immutable string class, that's final. Ruby has a
Symbol class that is used for the specific ideas you're referring to, to
make certain implementation details faster and more memory efficient.
It has nothing to do with the other "merits" of having immutable
strings.

You can add strings, but you can't add symbols,
nikolai
 
E

Eric Hodel

--Apple-Mail-3-731229470
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

2) Efficiency of VM will improve because Symbols and Strings can be
used
interchangeably.

Nope:

$ ruby
p "\0"
"\0".intern
"\000"
-:2:in `intern': symbol string may not contain `\0' (ArgumentError)
from -:2


--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-3-731229470
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB6EC9MypVHHlsnwQRAgkeAKCTotcqeak8KBxALKUyMUZAD1UZOwCgxsOz
mhhu7YhLWKr+MiFfQSEe8k8=
=ugW8
-----END PGP SIGNATURE-----

--Apple-Mail-3-731229470--
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top