I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?
T.
Hi,
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?
I/O tricks to emulate what is needed on Windows. Like the "gets"
command that locks the program, but shouldn't. That's one of the
things that the Perl people can still brag about (their programs can
run with the same code on Linux/Windows. Generally, maybe.) 
Overall I'm happy, though.
PS: Please, don't ask for static typing. lol 
Cheers,
Joao
···
On Sun, 16 Jan 2005 09:23:56 +0900, trans. (T. Onoma) <transami@runbox.com> wrote:
Rewrite it from scratch atop a multi-paradigm cross-platform VM such as the
one found at:
The syntax of Mozart is odd; a Ruby front end syntax to the back-end Oz VM,
though, would rock.
- Bob Calco
! -----Original Message-----
! From: trans. (T. Onoma) [mailto:transami@runbox.com]
! Sent: Saturday, January 15, 2005 4:24 PM
! To: ruby-talk ML
! Subject: Fwd: [suby-ruby] Your all time desired fundemental Ruby mod
!
! I'm taking a little poll.
!
! Let say you're Matz, but without any of the pressures of
! keeping up with a
! previous version of Ruby. What one thing above all others
! would you like to
! see differ about Ruby?
!
! T.
!
!
trans. (T. Onoma) wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a previous version of Ruby. What one thing above all others would you like to see differ about Ruby?
Real OS-based threading.
···
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
No more C code! Love ruby. Don't love ruby internals. I would like ruby to be written in ruby. That would be something I could love.
P.S. I'm working on this already. Email me for details.
···
On Jan 15, 2005, at 4:23 PM, trans. (T. Onoma) wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?
Couldn't think of much else.. well, there's the usual Marshallable Everything, Tail-call Optimization, Real Threads, Automatic Parallelism (ie. array.map{|x| do_something_expensive(x)} would automagically do all maps in parallel)
But here's one:
Syntax sugar for parameter pattern matching + reflection for it
def sum(x, 0)
x
when (_,100)
raise "100 is bad number"
when (x,y)
sum(x+1, y-1)
end
would mean
def sum(x, y)
case [x,y]
when [x,0]
x
when [x,100]
raise "100 is bad number"
when [x,y]
sum(x+1, y-1)
end
end
And you could query & edit them:
s = method(:sum)
s.patterns
# => {(x,0)=>Method, (_,100)=>Method, (x,y)=>Method}
s.patterns.delete((_,100))
s.patterns[(x,y)] = Method.new{|x,y| x+y}
Docstrings.
Let's see what Matz (the real one) says about this (in ruby-talk:20264):
"" Yes, indeed. Docstring is for man (or woman), so that - I think -
"" interpreter itself does not need to have them. Lisp (including Emacs)
"" and Smalltalk have interactive environment built in. Docstrings is
"" useful in such systems. Ruby is not. For example, in daemon program
"" written in Ruby, docstrings are nothing but memory burden.
But, for heaven's sake, I use ruby as an interactive environment quite
reguralry! In fact, it's a beautiful interactive environment (except for
docstrings lacking). Why to close ruby into a niche, just because it
fits there excellently?
(With appropriate docsstring syntax, the interpreter could either regard
them as comments or attach them as variables to the corresponding class
or method [depending on options], so the "memory burden" argument is not
valid.)
Csaba
···
On 2005-01-16, trans. (T. Onoma) <transami@runbox.com> wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?
trans. (T. Onoma) ha scritto:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a previous version of Ruby. What one thing above all others would you like to see differ about Ruby?
kill @@variables, and provide class_attr_reader and writer wich set/get instance variables in the class object. (IIRC there were no @@variables in early rubies so actually I would avoid keeping up ;).
Have a different threading approach, maybe Agent-like.
Provide more mixins (Readable/Writable/Seekable/Map).
Base the IO system on asynchronous event driven stuff such as libevent. I also found funny that in ruby-land people often wants OS threads and in python-land were they have them people often wants asynchronous stuff (i.e. twisted)
Hi --
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?
I would be happy to see class variables (@@var) disappear. But I
don't like the idea of class_attr_reader and things like that. Just
use the existing attr_* methods, which Class objects already have just
as much access to as other objects. If a Class object needs its own
state, let it keep its own state. If it wants other objects to have
access to it, let it give them access.
Hand-in-hand with this, and for other reasons, I would like my
Kernel#singleton_class RCR to be accepted I think that would make
the whole singleton-class model enormously easier to explain and
grasp. Unfortunately it's still surrounded by a kind of mystique and
mystery for many people -- which is really too bad, since it's
actually so simple and transparent and cool.
David
···
On Sun, 16 Jan 2005, trans. (T. Onoma) wrote:
--
David A. Black
dblack@wobblini.net
Two very different things: a truly cross-platform GUI and IO's concurrency.
I'd like a Swing-like GUI. I don't want the same API or look-and-feel, but having one Ruby GUI that worked on all platforms without thinking or installing anything would be heavenly.
From http://www.iolanguage.com/Source/release/Io/_docs/IoProgrammingGuide.html#Concurrency
"Io [http//www.iolanguage.com] uses actors and transparent futures for concurrency. An actor can be thought of as an object oriented thread. ... When an object receives an asynchronous message it puts the message in its queue and, if it doesn't already have one, starts a light weight thread (a coroutine) to process the messages in its queue. Queued messages are processed sequentially in a first-in-first-out order. Control can be yielded to other coroutines by calling 'yield'."
Jim
···
On Jan 15, 2005, at 7:23 PM, trans. (T. Onoma) wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?
--
Jim Menard, jimm@io.com, http://www.io.com/~jimm/
"If the Computer is a universal control system, let's give kids universes
to control." -- Theodore H. Nelson (1974)
Native thread support (maybe go hog wild and support native and lightweight threads so you can multiplex them 
)
-Brian
···
On Jan 15, 2005, at 7:23 PM, trans. (T. Onoma) wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?T.
C-core lazy generators (or Icon's 'suspend', though I'm not sure how
well that will play with the rest of ruby).
martin
···
"trans. (T. Onoma)" <transami@runbox.com> wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?
trans. (T. Onoma) wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a previous version of Ruby. What one thing above all others would you like to see differ about Ruby?
T.
Support for a ruby compiler.
trans. (T. Onoma) wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up
with a
previous version of Ruby. What one thing above all others would you
like to
see differ about Ruby?
T.
I vote for using a leading underscore instead of "@" sign for instance
variables. Perhaps a leading double underscore for "@@" (class
variables).
class Foo
__var = 23
def initialize
_x = 1
end
end
Looks a little purrrtier to me.
Too Pythonic? Too difficult to parse?
Oh, and add a Boolean class.
Regards,
Dan
PS - How the heck can I force indentation when posting via Google
Groups? Give me a pre tag!
1) First of all, a faster VM, including opcode (YARV ?)
2) A "strict mode" for instance variables (like perlish my @var or
attr_reader style declaration) - typos are quite subtle if they raise no
Exception immidiatly
3) Support for role-based programming.
ad 3) Solving the last ruby quiz, I used the following workaround for a
simple role change (only 1 role). Are there more sophisticated
solutions/frameworks available ?
#!/usr/bin/ruby
class Role
def initialize(object)
@__o__= object
end
def method_missing(symbol,*args)
@__o__.send(symbol,*args)
end
def __role__=(object)
@__o__ = object
end
undef_method :class,:display,:dup,:initialize_copy,:inspect,:instance_eval
undef_method :instance_of?,:instance_variable_get,:instance_variable_set
undef_method :instance_variables,:is_a?,:kind_of?,:method,:methods
undef_method :private_methods,:protected_methods,:public_methods
undef_method :remove_instance_variable,:respond_to?,:send
undef_method :singleton_method_added,:singleton_method_removed
undef_method :singleton_method_undefined,:singleton_methods
undef_method :to_a,:to_s,:type
end
# Testing
class Leaf
attr_accessor :animal
end
class Node
attr_accessor :c1,:c2
end
a = Role.new(Leaf.new)
puts a.inspect
puts a.class
b = Role.new(Leaf.new)
a.__role__=Node.new
a.c1=b
puts a.inspect
puts a.class
···
On Sun, 16 Jan 2005 09:23:56 +0900, trans. (T. Onoma) wrote:
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?T.
What one thing above all others would you like to see differ
about Ruby?
Get rid of RUBYOPT !!!
gegroet,
Erik V.
1. Consistent, concise syntax, with one simple way to do things.
2. Type inference.
3. A move to a more purely functional approach in the libraries (i.e.,
String.gsub stays, but String.gsub! goes.)
cjs
···
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.NetBSD.org
Make up enjoying your city life...produced by BIC CAMERA
Glenn Parker wrote:
trans. (T. Onoma) wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a previous version of Ruby. What one thing above all others would you like to see differ about Ruby?
Real OS-based threading.
seconded.
+10
···
Glenn Parker <glenn.parker@comcast.net> wrote:
Real OS-based threading.
--
Luc Heinrich - lucsky@mac.com
No, "memory burden" is quite valid. Come up with a clean way for Ruby
to have docstrings, but yet easily allow someone to dump them if
necessary. I find I rarely use Ruby for serious work interactively
(e.g., I do so when verifying stuff). In this case, I feel that it's
probably better that we have the ri/irb integrations that are ongoing
than docstrings.
-austin
···
On Sun, 16 Jan 2005 18:21:08 +0900, Csaba Henk <csaba@phony_for_avoiding_spam.org> wrote:
On 2005-01-16, trans. (T. Onoma) <transami@runbox.com> wrote:
> I'm taking a little poll.
>
> Let say you're Matz, but without any of the pressures of keeping up with a
> previous version of Ruby. What one thing above all others would you like to
> see differ about Ruby?
Docstrings.Let's see what Matz (the real one) says about this (in ruby-talk:20264):
"" Yes, indeed. Docstring is for man (or woman), so that - I think -
"" interpreter itself does not need to have them. Lisp (including Emacs)
"" and Smalltalk have interactive environment built in. Docstrings is
"" useful in such systems. Ruby is not. For example, in daemon program
"" written in Ruby, docstrings are nothing but memory burden.But, for heaven's sake, I use ruby as an interactive environment quite
reguralry! In fact, it's a beautiful interactive environment (except for
docstrings lacking). Why to close ruby into a niche, just because it
fits there excellently?(With appropriate docsstring syntax, the interpreter could either regard
them as comments or attach them as variables to the corresponding class
or method [depending on options], so the "memory burden" argument is not
valid.)
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca