I was thinking about Erlang a bit today, the fact that it’s objects
are all immutable and it’s usefulness to concurrency. So I began to
wonder, what would an Immutable Ruby look like?
T.
Hi,
In message “Re: Immutable Ruby”
on Fri, 29 Aug 2008 10:19:15 +0900, Trans [email protected]
writes:
|I was thinking about Erlang a bit today, the fact that it’s objects
|are all immutable and it’s usefulness to concurrency. So I began to
|wonder, what would an Immutable Ruby look like?
I have once dreamed of a such language, and had a conclusion that was
not Ruby at least, although a pretty interesting language.
matz.
On Fri, 29 Aug 2008, Trans wrote:
I was thinking about Erlang a bit today, the fact that it’s objects
are all immutable and it’s usefulness to concurrency. So I began to
wonder, what would an Immutable Ruby look like?
- Would it make setter methods effectively pointless?
The notion of a setter is probably very problematic.
- Overall, would it help or hurt efficiency/speed?
Depends on a single processor slower, on a high concurrency N core
processor, faster.
- Would it ruin Ruby’s elegance?
Yes, no. It becomes conceptually cleaner. The garbage collection becomes
cleaner and easier.
I suspect it will force you to think to really really think about
which class owns which other class.
- No more #<<
Nor any ! method.
- Is such a thing even possible?
Sort like Star Trek… “It’s life Jim, but not as we know it”
To find out what it would be like replace every
Blah.new(arg1,arg2…)
with
Blah.new(arg1,arg2…).freeze
John C. Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [email protected]
New Zealand
Hi –
On Sat, 30 Aug 2008, Trans wrote:
|wonder, what would an Immutable Ruby look like?
I have once dreamed of a such language, and had a conclusion that was
not Ruby at least, although a pretty interesting language.Does that mean you think Immutable Ruby would be so different a
language as to no longer be recognizable as Ruby? Perhaps so. The
prospect is very interesting to me nonetheless. If I did not have to
worry so much about $$$$, I would very much like to try my hand at
writing an Immutable Ruby in Erlang.
I don’t think it would be recognizable as Ruby. Consider this:
$ ./ruby -ve ‘a = Object.new; class << a;
def talk; print “hi\n”; end;
end; a.talk’
ruby - version 1.0-971225 (i686-linux)
hi
If you change print to puts, it won’t know what you mean. And don’t
ask a for its .methods either. In other words, per-object differential
behavior was part of Ruby before puts and methods were. I’d say it’s
pretty fundamental 
(If anyone wants my hacked copy of Ruby 1.0 (hacked to compile on gcc
4.0, for some definitions of “compile”), let me know.)
David
On Aug 29, 12:18 am, Yukihiro M. [email protected] wrote:
not Ruby at least, although a pretty interesting language.
Does that mean you think Immutable Ruby would be so different a
language as to no longer be recognizable as Ruby? Perhaps so. The
prospect is very interesting to me nonetheless. If I did not have to
worry so much about $$$$, I would very much like to try my hand at
writing an Immutable Ruby in Erlang.
T.
John C. wrote:
To find out what it would be like replace every
Blah.new(arg1,arg2…)
with
Blah.new(arg1,arg2…).freeze
$".freeze
require “fileutils”
Life is not good. Beam me up Scotty.
On Aug 28, 10:07 pm, John C. [email protected] wrote:
To find out what it would be like replace every
Blah.new(arg1,arg2…)
with
Blah.new(arg1,arg2…).freeze
Almost. From my understanding Immutable objects can have internal
changing state as long as it is never exposed to the outside world.
For instance, memoize is a good example.
Am I right about that?
T.
From: Trans [mailto:[email protected]]
If I did not have toworry so much about $$$$, I would very much like to try my hand at
writing an Immutable Ruby in Erlang.
Sounds similar to what Tony’s thinking about with Reia.
http://wiki.reia-lang.org/wiki/Main_Page
On Fri, Aug 29, 2008 at 2:21 PM, Steven P. [email protected]
wrote:
Sounds similar to what Tony’s thinking about with Reia.
http://wiki.reia-lang.org/wiki/Main_Page
Yep, thanks for mentioning it.
- No more #<<
Reia doesn’t support << for syntactic reasons (in Reia this designates
the beginning of a “binary”) but it will allow “mutation” of its
pseudo-objects (Lists, Dicts, etc.) using a “magic rebinding”
technique (not presently implemented). This does differ somewhat from
Ruby’s semantics. Consider the following in Ruby:
a = b = [1,2,3]
=> [1, 2, 3]
a << 4
=> [1, 2, 3, 4]
b
=> [1, 2, 3, 4]
Here a and b reference the same Array, so when you mutate a the
contents of b also change. However, in Reia (this example actually
works from its current interactive interpreter):
a = b = [1,2,3]
=> [1,2,3]
a.push(4)
=> [1,2,3,4]
b
=> [1,2,3]
Reia allows rebinding by compiling to static single assignment form
(currently in development). This decomposes places where variables
are potentially rebound into single assignment by keeping track of
versions of variables. When you a.push(4) in Reia, it (will
eventually be able to) create a new version of the a variable which is
bound to the new version of the list. However, the value of b does
not change.
Is this confusing? Hard to say. I personally don’t find it
confusing, but YMMV.
- No more Symbol vs. String!!!
Immutable strings are somewhat different from symbols. Erlang has
both (except it calls symbols “atoms”). Symbols work off of what’s
effectively a big global hash table. With immutable strings you can
have several copies which are identical but still require O(n)
comparisons and so forth.
Nor any ! method.
I plan on carrying over the method! convention and semantics into
Reia, FWIW. method? is coming along as well.
That said I find it nice the “default” approach in Ruby is to not
modify the receiver.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs