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?
* Overall, would it help or hurt efficiency/speed?
* Would it ruin Ruby's elegance?
* No more #<< 
* No more Symbol vs. String!!! 
* Is such a thing even possible?
T.
Hi,
In message "Re: Immutable Ruby" on Fri, 29 Aug 2008 10:19:15 +0900, Trans <transfire@gmail.com> 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.
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.
On Aug 29, 12:18 am, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
Hi,
In message "Re: Immutable Ruby" > on Fri, 29 Aug 2008 10:19:15 +0900, Trans <transf...@gmail.com> 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.
Hi --
Hi,
>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.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 Sat, 30 Aug 2008, Trans wrote:
On Aug 29, 12:18 am, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
In message "Re: Immutable Ruby" >> on Fri, 29 Aug 2008 10:19:15 +0900, Trans <transf...@gmail.com> writes:
--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!
From: Trans [mailto:transfire@gmail.com]
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.
Sounds similar to what Tony's thinking about with Reia.
http://wiki.reia-lang.org/wiki/Main_Page
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.
On Fri, Aug 29, 2008 at 2:21 PM, Steven Parkes <smparkes@smparkes.net> wrote:
--
Tony Arcieri
medioh.com
